Возникла потребность соединить две сети по VPN. В качестве VPN серверов выбраны FreeBSD 6.2. Это надежно и понятно.
Абсолютно понятная документация по этому поводу находится здесь (это глава их хэндбука): http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html или на русском http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/ipsec.html
Конфигурация следующая:
Есть два офиса с выходом в Интернет.
В одном офисе сетка 10.0.0.0/16
В другой - 192.168.0.0/16
Маска и так и там именно 16 - исторически сложилось.
Итак, делаю VPN на базе FREEBSD.
Общая схемка:
Lnic - сетевуха в докалку
Inic - сетевуха в интет (к ADSL модему)
10.0.0.0/16 - (FBSD: Lnic: 10.0.10.220, Inic: A.B.C.D) - ADSL :internet: ADSL - (FBSD: Inic: W.X.Y.Z, Lnic: 192.168.0.3) - 192.168.0.0/16
Все настроил. IPSec пока не включаю, сначала так проверить решил.
С 192.168.0.37 спокойно пингуются все машины в 10.0.0.0. Можно telnet-ом зайти на сервер почты в 10.0.0.0, можно на RDP порты.
Далее соединяюсь с 192.168.0.37 по RDP на 10.0.10.2 - работает, все классно.
Концигурация racoon.conf
path include "/usr/local/etc/racoon";
path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log debug;
# "padding" defines some padding parameters. You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}
# Specify various default timers.
timer
{
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 20 sec; # maximum interval to resend.
persend 1; # the number of packets per send.
# maximum time to wait for completing each phase.
phase1 30 sec;
phase2 15 sec;
}
remote anonymous
{
exchange_mode main,base;
lifetime time 24 hour;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous
{
#pfs_group 2;
lifetime time 12 hour ;
encryption_algorithm rijndael ;
authentication_algorithm hmac_sha1 ;
compression_algorithm deflate ;
}
Ради проверки решил соединится по RDP с самым важным сервером сети (1С-ка) по Адресу 10.0.10.100. И тут облом. Просто таймаут соединения. Смотрю trafshow на Freebsd по время соединяеия. Вижу как пакет пошел с 192.168.0.37 на 10.0.10.100 и вижу как пакет пошел обратно. Смотрю на netstat на 10.0.10.100 вижу, что есть коннект с 192.168.0.37. Но RDP все равно не отвечает. Просто тайм-аут соединения. Пробую Citrix. У него полоска соединения доходит по середины и кирдык. Опять таум аут. Беру телнет - коннектюсь с 192.168.0.37 на 10.0.10.100. Есть коннект. Пинг есть, жто я уже говорил. Пересаживаюсь на другую машину в 192.168.0.0/16 и делаю все это оттуда - ровно то же самое.
Думал ладно, а вообще оно работает?
Захожу по RDP на 10.0.10.2, с него по RDP 10.0.10.100 - БЕЗ ПРОБЛЕМ. Т.е. со своего сегмента пускает. А вот дальше - ФАНТАСТИКА.
С машины 10.0.10.100 спокойно соединяюсь и работаю по RDP с 192.168.0.37.
Т.е. получается, что с 192.168.0.37 нельзя по RDP зайти на 10.0.10.100, а обратно - без проблем.
Пошел проверил настройки terminal service. Все хорошо, отвечать на всех интерфейсах. Проверил firewall - все вЫключено. Все чисто.
Пробился как дурак 6 часов, ушел в половину первого ночи без результатов.
Пока ехал домой и перед сном пришла идея, что может быть с MTU проблема (это не провайдер, а размер пакета). Типа не пролазят через ADSL большие пакеты. Проверил даже - да, пинг с пакетом больше 1200 не лезет. Но извините, а как же тогда коннект по RDP в обратную сторону работает? Почему с 10.0.10.2 пашет все без проблем вообще?
Системы:
192.168.0.37 - xp pro
10.0.10.100 - windows 2003
10.0.10.2 - xp pro
Ну вот, кинул это сообщение в форум на sysadmins.ru
В итоге один добрый человек (figley) показал вот, что:
Пожалуй mtu действительно имеет значение, в частности удалось выяснить следующее: Вот процедура развязывания сессии rdp:01:18:53.629258 IP (tos 0x0, ttl 127, id 15712, offset 0, flags [none], length: 48) MY.MY.MY.MY.1356 > TS.TS.TS.TS.3389: S [tcp sum ok] 4115545609:4115545609(0) win 65535
01:18:53.634944 IP (tos 0x0, ttl 121, id 2313, offset 0, flags [none], length: 48) TS.TS.TS.TS.3389 > MY.MY.MY.MY.1356: S [tcp sum ok] 1579795568:1579795568(0) ack 4115545610 win 16384
01:18:53.635383 IP (tos 0x0, ttl 127, id 15713, offset 0, flags [none], length: 40) MY.MY.MY.MY.1356 > TS.TS.TS.TS.3389: . [tcp sum ok] 1:1(0) ack 1 win 65535
01:18:53.636019 IP (tos 0x0, ttl 127, id 15714, offset 0, flags [none], length: 76) MY.MY.MY.MY.1356 > TS.TS.TS.TS.3389: P [tcp sum ok] 1:37(36) ack 1 win 65535
01:18:53.642593 IP (tos 0x0, ttl 121, id 2314, offset 0, flags [DF], length: 51) TS.TS.TS.TS.3389 > MY.MY.MY.MY.1356: P [tcp sum ok] 1:12(11) ack 37 win 65499
01:18:53.643292 IP (tos 0x0, ttl 127, id 15715, offset 0, flags [none], length: 452) MY.MY.MY.MY.1356 > TS.TS.TS.TS.3389: P 37:449(412) ack 12 win 65524
01:18:53.652224 IP (tos 0x0, ttl 121, id 2315, offset 0, flags [DF], length: 1200) TS.TS.TS.TS.3389 > MY.MY.MY.MY.1356: . 12:1172(1160) ack 449 win 65087
01:18:53.652237 IP (tos 0x0, ttl 121, id 2316, offset 0, flags [DF], length: 367) TS.TS.TS.TS.3389 > MY.MY.MY.MY.1356: P 1172:1499(327) ack 449 win 65087
MY.MY.MY.MY - ip-адрес клиента.
TS.TS.TS.TS - ip-адрес севера терминалов.
Последние два пакета в данном выводе (id 2315 и id 2316) имеют флаг do not fragment и суммарный объем в 1567 (с заголовками). То есть первый из них целиком занимает MTU. (В данном случае на сервере терминалов на интерфейсе ethernet установлен MTU=1200).
Таким образом, в том случае, если, например, на TS MTU=1500, а на Freebsd на интерфейсе 10.0.10.220 MTU<1500 (скажем, я ставил TS MTU=1500, freebsd-eth MTU=1200), данный пакет до клиента не пролезает, и клиент получает сообщение - см. приложение.
Зачем серверу терминалов нужно ставить DF на исходящие пакеты - этого я не знаю.
PS: Правда, остается непонятным, почему в такой ситуации можно спокойно зайти на 10.0.10.2.
Далее выяснилась другая интересная вещь. Цитата от "figley" с форума www.sysadmins.ru:
"Кстати, если кому интересно, разобрался, почему можно зайти на winxp: размер того пакета, который является ответным на пакет клиента размером 452b, и несет флаг DF составляет в случае XP не 1567b, а 373b"
Вот так.
Я поискал в данные по MTU для Windows и нашел две статьи:
http://support.microsoft.com/default.aspx?scid=kb;en-us;q314825
http://support.microsoft.com/kb/314053/EN-US/
Так как времени экспериментировать не было, то на 10.0.10.100
1) Добавлен и установлен MTU 1024 байта (а просто, число хорошее)
2) Добавлен и установлен EnablePMTUBHDetect в 1
Есть подозрение, что хватило бы одно из них (причем возможно, что любого), но так как бегать между двумя офисами на расстоянии 1024 метра друг от друга у меня нет ни времени ни сил, у заказчика установки тоже нет никакого желания, то я сделал все разу и, О ЧУДО!, в лесу сдохли все волки и медведи! Все работает, RDP пашет, CITRIX пашет, дети смеются, бабы довольны!
Осталось загадкой одно. Почему windows 2003 поставленная на 10.0.10.2 с того же диска, что и на 100 работала по RDP? Отличие в том на на 10.0.10.100 стоит еще Citrix и MS SQL. Может быть уровень обновления сиситем или Citrix что-то меняют в настройках сети или обновление системы меняет сам RDP протокол?
2007/01/28
artem@artem.ru
Огромное спасибо за статью!!!
Сам столкнулся с этим чудом, не знал как победить. Не верил, что МТУ может влиять на соединение с терминальным сервером.
В моей сети концентратор DLINK. Расшаренные ресурсы на SAMBA работали как система ниппель - туда скорость отличная, оттуда только 200-300Кбит/сек.
Оказалось, что дело тоже в МТУ. Очевидно, DLINK как-то странно работает с пакетами 1500. Когда установил на FreeBSD МТУ меньше - SAMBA летает. Но отваливался терминальный сервер.
Теперь понятно, в чем дело и что делать!
руками ставить мту на винде не обязательно.
ставим EnablePMTUDiscovery и EnablePMTUBHDetect, и мту будет устанавливаться динамически, в зависимости от узких мест, или, в случае обнаружения "черных дыр", будут разрешаться фрагментированные пакеты:
http://support.microsoft.com/?scid=kb%3Bru%3B314053&x=9&y=10
MTU
Раздел: Tcpip\Parameters\Interfaces\код(ID)_адаптера
Тип параметра: REG_DWORD – число
Допустимые значения: 68 - MTU_используемой_сети
По умолчанию: 0xFFFFFFFF
Описание: этот параметр переопределяет заданное по умолчанию значение MTU для сетевого интерфейса. MTU – это максимальный размер пакета в байтах, который может быть передан транспортным протоколом по используемой сети. Этот размер включает и заголовок транспортного протокола. Следует помнить о том, что датаграмма IP может быть разбита на нескольких пакетов. Если заданное значение превышает значение, используемое в сети по умолчанию, будет использоваться значение MTU по умолчанию. Если задать значение меньше 68, будет использоваться значение MTU, равное 68.
EnablePMTUDiscovery
Раздел: Tcpip\Parameters
Тип параметра: REG_DWORD – логическое
Допустимые значения: 0,1 (False или True)
По умолчанию: 1 (True)
Описание: если для этого параметра установлено значение 1 (True) TCP пытается обнаружить максимальный блок данных (MTU или максимальный размер пакета) для передачи по каналу, ведущему к удаленному узлу. Обнаружив MTU маршрута и ограничив сегменты TCP этим размером, протокол TCP может избежать фрагментации на маршрутизаторах на пути, соединяющем сети с разными MTU. Фрагментация отрицательно сказывается на производительности протокола TCP и может вызывать перегрузку сети. Установка для этого параметра значения 0 приводит к ограничению размера MTU до 576 байт, которое используется для всех соединений, осуществляемых со всеми компьютерами, за исключением компьютеров локальной подсети.
EnablePMTUBHDetect
Раздел: Tcpip\Parameters
Тип параметра: REG_DWORD – логическое
Допустимые значения: 0,1 (False или True)
По умолчанию: 0 (False)
Описание: если для этого параметра установлено значение 1 (True) TCP при обнаружении MTU маршрута будет пытаться найти маршрутизаторы-«черные дыры». Маршрутизатор-«черная дыра» не возвращает сообщения «Destination Unreachable» протокола ICMP, если ему требуется фрагментировать IP-датаграмму, фрагментация которой запрещена. Протоколу TCP необходимо получать эти сообщения для обнаружения маршрута MTU. Если эта функция включена и если несколько его повторных передач оказываются неподтвержденными, TCP будет пытаться отправлять пакеты без флага Don't Fragment. Если будет получено подтверждение приема пакета, размер MSS будет уменьшен, а флаг Don't Fragment установлен на следующих пакетах подключения. Включение обнаружения «черной дыры» увеличивает максимальное количество повторных передач, выполняемых для отдельного пакета.
Мишки очень любят мед....
ElDeRone
все же МТУ задавать обязательно, не пашет без этого, как поставил сразу заработало
(C)1999-2021 Артем Кучин
Email: artem@artem.ru
На письма без темы или без имени отправителя не отвечаю
При использовании материалов ссылка на сайта www.artem.ru обязательна! Автор оставляет за собой право отказать в праве использования материалов на безвозмездной основе без объяснения причин. Материалы сайта защищены законом об авторских и смежных правах.
Цена домена: 1 500 000 руб.