Объединение 3-х сетей и подключение компов
-
Адресация, собственно, везде разная. В общем я как раз и пошел путем создания по одному серверу на филиал (подключил через PSK), и еще один Remote Access TLS+User для удаленных пользователей. У каждого из серверов свой пул адресов. Еще дополнительно прописал каждому серверу маршруты на остальные сети. В принципе вроде работает… Один вопрос остался: DNS. При подключении PSK настроек для DNS нет, собственно имена не резолвятся. Как решить? Ну и не решился вопрос с подключением PKI, не работает и все тут, потому и обошел.
Железо там виртуальное, в смысле, на физ серваке несколько вирт шлюзов и машинок вертится, а так Xeon-ы. На филиалах Sempron+2Гб. -
При подключении PSK настроек для DNS нет, собственно имена не резолвятся. Как решить?
Сервер работает в remote access или p2p в этом случае ?
Передать адрес dns сервера клиентам возможно, указав в доп. настройках сервера (при remote access точно работает) :
push "dhcp-options DNS x.x.x.x"
P.s.
http://www.techques.com/question/2-360308/Local-domain-DNS-resolution-not-working-using-OpenVPN-on-a-pfSense-box
https://forum.pfsense.org/index.php?topic=70831.msg387956#msg387956 -
Проблема в обоих случаях. Но в Remote Access можно передать список DNS серверов клиентам (опция Provide a DNS server list to clients), вроде как должно работать, пока еще не тестил. А вот в случае Peer-to-Peer такой опции нет, и не понятно как передать DNS серверы между сетями… Или может проще решить проблему на уровни самих DNS серверов прописав каждому форвард на остальные по IP. Или ошибаюсь?
-
@ valentin
Или может проще решить проблему на уровни самих DNS серверов прописав каждому форвард на остальные по IP
Пробуйте.
По ссылкам моим - читали ?
А вот в случае Peer-to-Peer такой опции нет
Что мешает использовать режим Remote access ?
-
Что мешает использовать режим Remote access ?
Соединить 2 psSense можно только с помощь Peer-to-Peer, а там вариации SSL/TLS или SharedKey.
При SSL/TLS непонятные проблемы с маршрутизацией, т.е. все так же настроено как и при SharedKey но не видятся сети и все тут, я уже писал.
Удаленные пользователи и подключаются через Remote access (SSL/TLS+User).
И да, по ссылке 2 вроде то, что надо. Эту опцию нашел, но не до конца понял то это или нет.
Ну и вот еще вытекающий вопрос на счет маршрутов в режиме PKI: почему роутер с DD-WRT подключается и без доп настроек видит сеть сервака, а если клиент на pfSense, то не видит, маршруты те же что и при Peer-to-Peer. -
Соединить 2 psSense можно только с помощь Peer-to-Peer, а там вариации SSL/TLS или SharedKey
.
Чего?! И откуда такой вывод, любезный?
-
Ну, например, в настройках подключения клиента только эти 2 опции в выпадающем списке.
Если есть другие варианты подскажите как их отыскать, я ж только учусь… -
Верно, посыпаю голову пеплом.
Глупое предложение, но попробуйте :
Сервер в Remote access (ssl\tls) , клиент - p2p (ssl\tls). CA и сертификаты для клиента брать , ес-но, с сервера. -
В общем, проблема мне кажется вот в чем, хотя может я чего-то не понимаю в маршрутизации:
в таблицах маршрутизации маршрут сервера в сеть впн прописан как 11.0.0.0/24 Gateway 11.0.0.2, а маршрут клиента в сеть сервера как 11.0.0.1/32 Gateway 11.0.0.5. Так вот, сети получается разные в маршрутах, но почему??? Я в настройках везде указал Tunnel Network 11.0.0.0/24, в Advanced "route <сеть (сервера для клиента)/(клиента для сервера)> 255.255.255.0" . Добавление в Advanced "route 11.0.0.0 255.255.255.0" ничего не дает, маршрут появляется но через него трафик не ходит. Да, и с клиента сеть сервера пингуется, а вот с сервера клиентская нет. Итог, проблема маршрутизации при подключении типа Peer-to-Peer (SSL/TLS) поскольку при аналогичных настройках Peer-to-Peer (Shared Key) все работает. Как решить проблему может кто подсказать? Может нужно как-то сообщить разработчику о глюке (… или это не глюк, а у меня руки кривоваты). Или не заморачиваться и пользоваться Peer-to-Peer (Shared Key). Кстати, для удаленных пользователей нормально работает Remote Access (SSL/TLS) и не приходится каждый раз вводить имя пользователя и пароль.
К стати, сделал и по вашему совету:Глупое предложение, но попробуйте :
Сервер в Remote access (ssl\tls) , клиент - p2p (ssl\tls). CA и сертификаты для клиента брать , ес-но, с сервера.Те же яйца только в профиль… Коннект есть, пинги только от клиента в сеть сервера.
-
А если на сервере на LAN повыше добавить правило вида
IPv4 * LAN net * х.х.х.х/уу * * none
где х.х.х.х/уу - сеть клиента?
-
Вообще LAN сейчас полностью открыт. Ну и дело в том, как я уже писал, что пинги с pfSense клиента ходят в сеть сервера, с компов в сети клиента нет. И с сервера вообще ничего не ходит к клиенту.
-
Помнится мне , что в последних версиях pfsense на LAN нужно явно писать (в случае VPN) к какой сети (и через какой шлюз - неуверен) даете доступ.
Так что послушайте совета ув. pigbrother . Просто открыть на LAN доступ уже "не канает".P.s. Совет : включайте логирование fw и внимательно смотрите какой трафик блокируется.
-
Это не мой совет, это совет сообщества, включая уважаемго rubic, вас, werter и многих других.
Вообще с переходом на 2.1.х работа OVPN изменилась и трудно сказать, что в лучшую сторону. Англоязычные ветки тоже полны сообщений о проблемах с OVPN.
Боюсь показаться ретроградом, но в головном офисе после экспериментов с версиями от 2.1.х до тестовой 2.2 вообще оставил в продакшн в качестве OVPN-сервера 2.0.3 как максимально предсказуемую и беспроблемную. -
Ну, в принципе, дать доступ явно, не проблема, НО, все же, при подключении с помощью Shared Key трафик то бегает. Т.е. разница ТОЛЬКО в способе аутентификации, получается фаервол тут ни при чем, он же является независимым компонентом. А вот настройки маршрутизации по умолчанию для разных способов подключения теоретически могут быть разными (зависит от разработчика). Опять же, таблицы маршрутов правильные и практически одинаковые для обоих способов подключения (если верить тому, что показывает pfSense), и от клиента то траф. ходит, значит, опять таки, ФВ ни при чем.
-
Я тоже начинал с PSK. Потом пришлось перейти на PKI. И приведенное выше правило мне помогло
Опять же, таблицы маршрутов правильные и практически одинаковые для обоих способов подключения (если верить тому, что показывает pfSense), и от клиента то траф. ходит, значит, опять таки, ФВ ни при чем.
OVPN в 2.1.х - своеобразный квест. -
ОК, спасибо, буду пробовать…
Попробовал, ничего не дало. Может еще какие-то правила Вы применяли? Я поставил предложенное в самый верх, пинги ходят так же только с клиента к серверу и только с самого pfSense. -
P.s. Совет : включайте логирование fw и внимательно смотрите какой трафик блокируется.
!!!
-
Да не в ФВ это дело! Там какая-то беда с маршрутами, причем это не видно в таблице маршрутов. Все же работает с другими настройками аутентификации, как это может быть связано с ФВ???
Короче интересная штука творится! ВПН сеть 11.0.0.0/24, сервер получает адреса 11.0.0.2 - шлюз, 11.0.0.1 - локальный адрес, клиент соответственно 11.0.0.5 - шлюз и 11.0.0.6 - адрес. Так вот, при трассировке от клиента адреса 11.0.0.5 первый хоп идет на 11.0.0.1, т.е. лок. адрес сервера, дальше глухо. А вот с сервера пинг его же шлюза 11.0.0.2 вообще не проходит. Т.е. таки проблемы маршрутов, но почему ???
Кстати! А порт для SSL/TLS открывать не надо в ФВ? -
Кстати! А порт для SSL/TLS открывать не надо в ФВ?
Вы будете первым в мире , кто это сделает.
-
Ну тогда остается ждать нового релиза, поскольку текущий видимо не стабилен в плане OpenVPN…
