IPSec-туннель на двух DFL-210

Рано или поздно приходится ломать голову над тем, как бы объединить несколько сетей компании (или домашних – для извращенцев ;)). В принципе, все логично – бизнес растет, развивается, ширится в регионы и так далее. Лично мне захотелось для начала объединить домашнюю сеть с рабочей. PPTP работало давно и успешно (да и сейчас никуда оно не делось), но лениво каждый раз поднимать VPN чтобы глянуть не отключился ли какой-нибудь свитч. Вообще говоря, как поднять IPSec-туннель достаточно понятно расписано на сайте D-Link и успешно гуглится по запросу в стиле “DFL IPSec”. Я же, традиционно, буду жаловаться на жизнь и рассказывать про подводные камни.

Итак, шаг первый – настраиваем все по инструкции. Хотя лучше будет ее изучить и сделать все по-своему. Тупое следование шаблону хорошо далеко не всегда. Если в кратце, то придумываем Pre-Shared Key, говорим, куда подключаться и какие подсети где находятся.

Во-вторых, следует на обеих сторонах создать разрешающие правила. Иначе оба роутера будут тупо блокировать пакеты друг от друга. Здесь следует чуток почесать репу и решить, нужен ли нам полностью прозрачный туннель или надо какие-то особые разрешения. Ну там, например, можно раздавать через туннель интернет, если на удаленной точке только локалка к провайдеру. Или netbios закрыть наглухо. В общем, думайте сами, решайте сами. Настоятельно рекомендую разрешить ICMP. Хотя бы временно, на период отладки и настройки.

Третье – рекомендую исправить маршрутизацию. Стандартные опции не слишком плохи, но мы же делаем все как истинные джедаи, верно? Короче, убираем в настройках интерфейса ВСЕ опции маршрутизации и создаем их руками. Идем в таблицу main и там создаем новый маршрут. Куда – в удаленную сеть, шлюз не указываем. Маршрут пойдет через туннель, метрику ставим в соответствии с религией, но можно не заморачиваться и поставить стандартное значение 90. Обязательно ставим мониторинг маршрута с контролем линка – если туннель отвалится, логический линк тоже погаснет.

Тест – запускаем пинг и трассировку с одной стороны в другую. И потом обратно. Убедимся, что туннель взлетел и заработал. Пляшем и танцуем 🙂

А теперь расскажу про средней величины булыжник, об который я больно споткнулся. Проблема вылезла совершенно неожиданно и заключалась в какой-то очень нестабильной работе туннеля. Исходные данные следующие – пинги в обе стороны бегают прекрасно, в том числе и тяжелый. А вот netbios работает из рук вон плохо. Шары едва открываются, файлы отказываются копироваться или копирование регулярно отваливается с жалобами на отсутствие файла (ага, в самой его середине). RDP периодически теряет связь, железки с веб-интерфейсом не могут загрузить этот самый интерфейс целиком (несколько строк Html и все). При всем при этом подключение по PPTP проходит на ура и все работает в лучшем виде.

Куда копать? Правильно, в сторону MTU. Но вот беда – этот параметр можно поменять в куче мест и не очень понятно которое из них возымеет действие. Методом проб и ошибок выяснено, что настройка MTU в самом интерфейсе (в настройках туннеля) ничего не дает. Не очень понятно для чего нужен этот параметр. Зато в недрах файрвола обнаружился параметр TCP MSS VPN Max. На буржуйском форуме D-Link’а в одной из веток, не имеющего прямого отношения к нашей теме рекомендуют сделать его поменьше.

По всей видимости, этот параметр как раз и указывает какой максимальный MTU роутер согласится протолкнуть через VPN. По умолчанию, там стоит число 1400. В моем случае уменьшение его до 1380 сделало куда более стабильным RDP, а уменьшение до рекомендованных на форуме 1360 заставило работать веб-интерфейсы железа 🙂 Проблемы с сетевым окружением тоже вроде исчезли. И, наконец, скажу где искать этот волшебынй крыжик. Находится он в настройках системы. Расширенные настройки -> настройки TCP. Название указано выше по тексту.