О настройке FreeBSD VPN для связи Windows сетей и проблемы MTU

Возникла потребность соединить две сети по 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

Комментарии

2008-09-29 12:10:50 rambomax

Огромное спасибо за статью!!!
Сам столкнулся с этим чудом, не знал как победить. Не верил, что МТУ может влиять на соединение с терминальным сервером.
В моей сети концентратор DLINK. Расшаренные ресурсы на SAMBA работали как система ниппель - туда скорость отличная, оттуда только 200-300Кбит/сек.
Оказалось, что дело тоже в МТУ. Очевидно, DLINK как-то странно работает с пакетами 1500. Когда установил на FreeBSD МТУ меньше - SAMBA летает. Но отваливался терминальный сервер.
Теперь понятно, в чем дело и что делать!


2008-10-06 15:48:55 ElDeRone

руками ставить мту на винде не обязательно.
ставим 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 установлен на следующих пакетах подключения. Включение обнаружения «черной дыры» увеличивает максимальное количество повторных передач, выполняемых для отдельного пакета.


2008-12-04 04:57:15 Асик

Мишки очень любят мед....


2008-12-10 13:19:18 yolkov

ElDeRone
все же МТУ задавать обязательно, не пашет без этого, как поставил сразу заработало


Добавить комментарий

Ваше имя:
город: страна:
Комментарий:

Введите код "3029" -

Сообщение будет видно на сайте только после прочтения модератором!
Ваши данные будут запомнены в cookie для удобства. HTML запрещен.

(C)1999-2021 Артем Кучин
Email: artem@artem.ru
На письма без темы или без имени отправителя не отвечаю

При использовании материалов ссылка на сайта www.artem.ru обязательна! Автор оставляет за собой право отказать в праве использования материалов на безвозмездной основе без объяснения причин. Материалы сайта защищены законом об авторских и смежных правах.

Цена домена: 1 500 000 руб.