Сегодня мы поговорим с вами о site-to-site vpn. Причем построенных на Windows 2003 RRAS с использованием PPTP. А именно, мне хочется поделиться с вами своей историей, которая едва не взорвала мой мозг.
Начнем с того, что вышло из строя оборудование. Проще говоря, маршрутизатор сгорел. В результате этого пропала связь с одним из подразделений, и после недолгих размышлений было решено поднять VPN соединение. Следующим этапом было короткое обсуждение способов и применяемых технологий. В общем, после недолгого общения было решено пропустить через NAT соответствующие порты с обеих сторон и использовать RRAS+PPTP. Простенько и со вкусом. Сказано – сделано. В первую очередь был по диагонали просмотрен этот документ. В соответствии с ним, на отвечающей стороне был поднят и настроен RRAS в режиме VPN сервера. Кроме того, как требовалось в руководстве я настроил demand-dial интерфейс. При этом меня начал мучить вопрос, зачем нужен этот интерфейс на отвечающем роутере. Однако сходу на этот вопрос ответа не было. Кроме того я обратил внимание, что в инструкции требуется поставить галочку, которая создаст локального пользователя. Этот эпизод я благополучно пропустил мимо ушей, поскольку настройка отвечающего RRAS происходила на контроллере домена. Затем аналогичный сервер был настроен и на вызывающей стороне, вместе со всеми необходимыми demand-dial интерфейсами. Подключающейся стороне, само собой, должен был выдаваться адрес, отличный от обеих наружных подсетей. Кроме того, внутри существующей сетевой инфраструктуры применяется RIP2. Поэтому его я так же настроил на обоих RRAS.
Итак – файерволлы настроены, роутеры тоже. Устанавливаем подключение и … Вот тут началось страшное. Сначала я даже не понял что и как. Просто тупо несколько раз переподключался. Без особого эффекта, правда. Пинг идти совсем не хотел. Ну никак. Казалось что, несмотря на успешное подключение, канал не работает. Трасса доходила до начальной точки канала, со стороны подключающегося офиса, и все. Дальше глухо. Начались эксперименты с различными вариантами конфигурации. Менялись настройки RRASов. Прописывалась статика на роутерах. Черт его знает еще чего только не делалось. Все бестолку. Все это только запутывало. К сожалению со мной случается неприятная вещь.Когда кажется, что решение, оно вот, уже близко. Уже почти все заработало. Не получается совсем маленькая штучка. Вот сейчас я что-нибудь тут потыкаю, поклацаю, поменяю. Совсем немного. И оно заработает. В итоге это клацанье и тыканье еще больше запутывает, затуманивает мозги. Работа превращается в “эникеинг”. В общем, так и случилось в этот раз. Казалось – проблема где-то в маршрутизации. Вот, сейчас, я пропишу нужный маршрут и все полетит. Тут обнаружилось, что пинг доходит таки но другой стороны. Что физический интрефейс отвечающей стороны пингуется. Казалось вот-вот и все заработает. Быстрей, быстрей. В общем,ничего не вышло. Придя домой я ее какое-то время помучился. Потом решил попробовать на виртуальных машинах. Собрал конфигурацию. Внимательно прочитал инструкцию, в той ее части где описывалась пошаговая настройка. Вроде работало. Хотя проверить это было довольно сложно, поскольку связь между конечными точками туннеля была и без туннеля. В конечном итоге я лег спать в расстроенных чувствах.
На другой день. Я успокоился, не стал перебирать различные варианты настройки. Снес конфигурацию и настроил все заново, как требовала инструкция. Однако в этот раз адрес получающая сторона получала от DHCP. Запустил везде кучу снифферов и стал пинговать. Оказалось что туннель все таки работает. Однако маршрутизация на отвечающей стороне работает странно. И тут я, наконец, заметил, что статический маршрут, который настраивается при создании интерфейса, и должен был показывать в сеть офиса не создается. Я, в принципе, и раньше это замечал. Но почему-то пропустил мимо мозга. Странно, подумал я. Может RRAS глючит? Попробовал добавить его вручную из интерфейса RRAS. И тут меня постигла неудача. На отвечающей стороне не было поднятых туннельных интерфейсов, смотрящих в офис. Через кого же настраивать маршрут? Попытка настроить его через адрес удаленного интерфейса роутера? Может и так. Я сменил выдаваемые при подключении адреса с DHCP на ручные, как водится отличные от существующих. Маршрут через интерфейс вроде прописался, но в таблице не появился. Попытка сделать это через route add тоже не увенчалась успехом. Система сказала что шлюз находится в другой подсети. Логично, ничего не скажешь, так и есть. В итоге пакеты с отвечающего RRAS уходили черт его знает в какой космос.
И тут на меня снизошло. Я вспомнил, что когда я делал это на виртуалках, интерфейс на отвечающей стороне поднимался при подключении сам! А в текущем случае этого не происходит! Вот почему может не добавляться маршрут связанный с этим интерфейсом! Но как же так? В чем же дело? Ответ пришел сразу. Мои виртуалки не были контроллерами домена! Вот оно! Тут же стали ясны назначения и создаваемого пользователя, при настройке принимающего интерфейса, и самого этого интерфейса. Пользователь используется для того чтобы определить, какой из интерфейсов на отвечающей машине нужно поднять при подключении. И при этом он создаст нужный маршрут! ДА! По этому нельзя настраивать такое решение на контроллере домена, поскольку на нем нельзя создать локальных пользователей! И здесь наступает самый скорбный момент моего повествования [посыпает голову пеплом]. Я еще раз, самым внимательным образом просмотрел инструкцию на предмет описания процесса создания пользователя. Я ведь это пропускал сознательно, зная что на контроллере локальных пользователей нет. И что же я увидел?
On the Dial In Credentials page, type the password of the user account used by the calling router in Password and Confirm password, and then click Next. This step automatically creates a user account with the same name as the demand-dial interface that is being created. This is done so that when the calling router initiates a connection to the answering router, it is using a user account name that matches the name of a demand-dial interface. Therefore, the answering router can determine that the incoming connection from the calling router is a demand-dial connection rather than a remote access connection.
Вот так вот. Все. Целый день борьбы, снифферов, ломания и кипения мозга. А вся проблема в простой невнимательности к мелочам.
Однако на этом дело не кончилось. Ведь связь все равно нужна. В итоге решение вышло очень странным, но рабочим:
Я сделал два клиентских туннеля. Серверы RRAS настроены таким образом, чтобы весь трафик в другой офис шел через NAT. А подключающийся интерфейс получает адрес через DHCP. В итоге получается что туннельный интерфейс branch1 получает адрес из сети mainoffice, а трафик, идущий из сети branch в mainoffice идет через NAT. Таким образом на RRAS серверах не нужен статический маршрут. Обратное подключение настроено симметрично. С его настройкой тоже вышел казус. При настройке исходящего интерфейса в mainoffice я сразу попытался подключиться. И он подключился. Я даже не подумал об этом в тот момент. Это только потом я вспомнил, и поглядев в конфиг роутера убедился, что pptp порт на нем проброшен совсем на другой сервер. Но переделывать ничего не стал.
В общем, если будут вопросы по этому решению – обращайтесь :)
И, подводя итог вышесказанному
НУЖНО БЫТЬ ВНИМАТЕЛЬНЫМ ПРИ ЧТЕНИИ ДОКУМЕНТАЦИИ!
2 комментария:
Полезно, спасибо.
Стараюсь :)
Отправить комментарий