ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Ivanov                      2:5020/400     14 Oct 2002  13:23:33
 To : All
 Subject : Работа CIPE через NAT [было: traffic encryption]
 -------------------------------------------------------------------------------- 
 

 Hi All!
 
 Как выяснилось в беседах о "traffic encryption", реализация CIPE не работает
 через NAT/Masquerading в полном объёме, хотя в самом протоколе проблем с
 этим нет.
 Проблема вытекает из "симметричности" CIPE и возможной сменой исходящего
 порта в UDP пакете при прохождении его через маскарадинг. Можно настроить
 соответствующим образом DNAT (port forwarding) чтобы всё работало, но это
 требует наличие доступа к хосту выполняющему маскарадинг, что не всегда
 возможно. Так же с CIPE сложно работать если один из концов туннеля имеет
 динамический IP-адрес.
 
 Посему предлагаю расширить реализацию CIPE с целью решения вышеуказанных
 проблем.
 
 Опишу идею подробнее:
 
 Hазовем  (условно) сторону CIPE-туннеля инициирующую соединение (отсылающую
 первый пакет) - "клиентом". При этом клиент может иметь как динамический IP
 адрес, так и находиться за маскарадингом/NAT'ом.
 Другая сторона пусть называется "сервером". Сервер должен иметь
 фиксированный IP, _не_ находится за маскарадингом, но может находиться за
 корректно настроенным NAT/DNAT (т.е. чтобы в его исходящий пакетах не
 изменялся src port).
 
 Идея сводиться к модификации опции 'peer' позволив в ней явно _не_ указывать
 адрес/порт удалённого хоста (вместо адреса и/или порта указывать "*")
 
 например:
 
 # options.cipcb0  CIPE server configuration
 ptpaddr         10.0.0.5
 ipaddr          10.0.0.4
 me              555.555.555.555:4040  #  почему бы и нет ? :)
 peer            *:*
 key             11111111111111111111111111111111
 
 # options.cipcb0  CIPE client configuration
 ptpaddr         10.0.0.4
 ipaddr          10.0.0.5
 me              0.0.0.0:4040
 peer            555.555.555.555:4040
 key             11111111111111111111111111111111
 
 Сторона, у которой адрес и/или порт не указан явно будет работать в качестве
 сервера.
 Пока не определён до конца 'peer', сторона не высылает пакеты, а пассивно
 ждёт их от другой.
 При получении первого пакета, который успешно аутентифицируется (т.е. его
 удаётся расшифровать при помощи ключа) сервер настраивает туннель на IP
 адрес/порт пришедшего пакета, устанавливая опущенные параметры в 'peer'.
 Если очередной пакет приходит с другого адреса/порта (порт, например может
 поменяться при истечении таймаута соединения на хосте, выполняющем
 маскарадинг, а IP - в результате разрыва d-up соединения) выполняется еще
 одна перенастройка.
 Изменения адресов/портов можно писать в syslog.
 
 Если пакеты от клиента приходят с одного и того же IP, рекомендуется
 прописать этот адрес явно в 'peer' на сервере (для безопасности). Если с
 разных -- можно фильтровать разрешенные диапазоны адресов через iptables,
 etc. Если у клиента изменяется только IP адрес, рекомендуется прописать явно
 порт.
 
 Вроде всё.
 
 Замечания, предложения, критика? Делал ли кто подобное? Есть ли ещё идеи?
 Hужно ли это?
 
 Кто готов помочь в реализации и тестировании - прошу в мыло.
 
 С уважением,
 Владимир Иванов
 --- ifmail v.2.15dev5
  * Origin: A poorly-installed InterNetNews site (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор