OpenVPN PSK: Site-to-Site инструкция для обсуждения
-
Да, именно так и делал. LAN добавил, сделал Пасссивным.
Вот все маршруты. OpenVPN CLient лежит (там где коннект рвется, там и служба OpenVPN падает, может сервер, может клиент).
IPv4 Destination Gateway Flags Refs Use Mtu Netif Expire default 213.228.116.131 UGS 0 26259 1492 pppoe0 10.64.64.2 link#11 UH 0 0 1492 ppp2 10.122.66.247 link#11 UHS 0 6 16384 lo0 10.154.44.150 10.64.64.2 UGHS 0 174640 1492 ppp2 10.154.44.154 10.64.64.2 UGHS 0 11702 1492 ppp2 10.154.44.158 10.64.64.2 UGHS 0 11706 1492 ppp2 92.126.192.213 link#9 UHS 0 0 16384 lo0 95.191.130.4 213.228.116.131 UGHS 0 98 1492 pppoe0 127.0.0.1 link#8 UH 0 21776 16384 lo0 172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3 172.17.2.1 link#13 UH 0 0 1500 ovpnc3 172.17.2.2 link#13 UHS 0 0 16384 lo0 192.168.0.0/24 172.17.2.1 UG1 0 8989 1500 ovpnc3 192.168.10.0/24 link#3 U 0 7810096 1500 fxp0 192.168.10.254 link#3 UHS 0 0 16384 lo0 195.162.32.5 213.228.116.131 UGHS 0 2495 1492 pppoe0 195.162.41.8 213.228.116.131 UGHS 0 2395 1492 pppoe0 213.228.116.131 link#9 UH 0 0 1492 pppoe0
172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.
А как конфиг просмотреть QUAGGA OSPFd?
-
Да, именно так и делал. LAN добавил, сделал Пасссивным.
Вот все маршруты. OpenVPN CLient лежит (там где коннект рвется, там и служба OpenVPN падает, может сервер, может клиент).
IPv4 Destination Gateway Flags Refs Use Mtu Netif Expire default 213.228.116.131 UGS 0 26259 1492 pppoe0 10.64.64.2 link#11 UH 0 0 1492 ppp2 10.122.66.247 link#11 UHS 0 6 16384 lo0 10.154.44.150 10.64.64.2 UGHS 0 174640 1492 ppp2 10.154.44.154 10.64.64.2 UGHS 0 11702 1492 ppp2 10.154.44.158 10.64.64.2 UGHS 0 11706 1492 ppp2 92.126.192.213 link#9 UHS 0 0 16384 lo0 95.191.130.4 213.228.116.131 UGHS 0 98 1492 pppoe0 127.0.0.1 link#8 UH 0 21776 16384 lo0 172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3 172.17.2.1 link#13 UH 0 0 1500 ovpnc3 172.17.2.2 link#13 UHS 0 0 16384 lo0 192.168.0.0/24 172.17.2.1 UG1 0 8989 1500 ovpnc3 192.168.10.0/24 link#3 U 0 7810096 1500 fxp0 192.168.10.254 link#3 UHS 0 0 16384 lo0 195.162.32.5 213.228.116.131 UGHS 0 2495 1492 pppoe0 195.162.41.8 213.228.116.131 UGHS 0 2395 1492 pppoe0 213.228.116.131 link#9 UH 0 0 1492 pppoe0
172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.
А как конфиг просмотреть QUAGGA OSPFd?
/var/etc/quagga/ospfd.conf
проблема в этом маршруте:
172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3
quagga видит клиентский адрес упавшего туннеля через сервер и держит маршрут к нему в таблице,
соответственно openvpn, поднимая туннель, не может сконфигурировать интерфейс с таким адресом
почитайте тут:http://redmine.pfsense.org/issues/2712
http://forum.pfsense.org/index.php/topic,60231.0.htmlвроде были какие-то патчи, не помню чем дело кончилось
-
function openvpn_clear_route($mode, $settings) { if (empty($settings['tunnel_network'])) return; list($ip, $cidr) = explode('/', $settings['tunnel_network']); $mask = gen_subnet_mask($cidr); $clear_route = false; switch($settings['mode']) { case 'shared_key': $clear_route = true; break; case 'p2p_tls': case 'p2p_shared_key': if ($cidr == 30) $clear_route = true; break; } if ($clear_route && !empty($ip) && !empty($mask)) { list($ip1, $ip2) = openvpn_get_interface_ip($ip, $mask); $ip_to_clear = ($mode == "server") ? $ip1 : $ip2; mwexec("/sbin/route -q delete {$ip_to_clear}"); } }
Это часть патча, которая уже интегрирована в openvpn.inc - руками патчить ничего не надо. Смотрим и видим, что маршрут будет очищен только когда префикс tunnel network = 30 (if ($cidr == 30) $clear_route = true;).
Т.е. вместо 172.17.1.0/24, 172.17.2.0/24 ставим везде 172.17.1.0/30 и 172.17.2.0/30, должно работать. Во всяком случае, у меня на стенде работает с /30 и не работает с /24 -
1. Уважаемый Rubic, не могли бы Вы описать процедуру создания туннелей, с использованием OSPF, при нескольких филиалах, при WAN failover со-всех сторон?
2. Попробовал создать подключение двух филиалов к центральному офису, без OSPF, как и описано в первом посте - оба филиала отлично видят центральный офис, а вот друг друга - нет. Роуты в адвансед клиентов, естесственно, прописал. С шлюза филиала1, Traceroute до ip в сети филиала2 уходит в туннель, и там "оседает".
Таблица центрального офиса:
Таблица филиала1:
Таблица филиала2:
Traceroute с одного из филиалов:
В обоих филиалах Multiwan failover
3. Возможно ли как то клиентов из Remote Acceess тоже заставить видеть все эти три сети?
Заранее, благодарен!
-
1. Если нужна полная связность при любых обстоятельствах (кроме конечно падения обоих WAN на одной из площадок), то связывают WANы туннелями по принципу "каждый с каждым". Только накладно это в режиме PSK - при 3-х плошадках на каждом WAN надо иметь по 4 сервера/клиента OpenVPN. В OSPF потом просто добавляются все OpenVPN интерфейсы как активные, а все LANы - как пассивные.
2. С маршрутами, судя по всему, все в порядке. Поэтому смотрите логи файервола на центральном сервере, на сервере и клиенте филиала, который трассируете.
3. Прописать маршруты на клиентах, или настроить, чтобы VPN был маршрутом по умолчанию. Не понятно что за клиенты. -
1. Если нужна полная связность при любых обстоятельствах (кроме конечно падения обоих WAN на одной из площадок), то связывают WANы туннелями по принципу "каждый с каждым". Только накладно это в режиме PSK - при 3-х плошадках на каждом WAN надо иметь по 4 сервера/клиента OpenVPN. В OSPF потом просто добавляются все OpenVPN интерфейсы как активные, а все LANы - как пассивные.
2. С маршрутами, судя по всему, все в порядке. Поэтому смотрите логи файервола на центральном сервере, на сервере и клиенте филиала, который трассируете.
3. Прописать маршруты на клиентах, или настроить, чтобы VPN был маршрутом по умолчанию. Не понятно что за клиенты.1. Может посоветуете оптимальное решение для таких условий?
Лог Firewall центрального, при traceroute с pfs филиала 1 на машину в сети филиала 2.
Лог Firewall филиала 2, при traceroute с pfs филиала 1 на машину в сети филиала 2.
И кстати, если пытаюсь делать traceroute с машины в сети филиала 1 на машину в сети филиала 2 - trace вообще отправляется в сеть провайдера. То же самое и наоборот.
Если из филиала делаю trace на машины центрального, все идет как положено.3. Клиенты подключенные к серверу remote access поднятому тоже на центральном pfs (ноутбуки, телефоны и т.п.)
-
1. В режиме PKI OpenVPN сервер может обслуживать несколько клиентов, т.е. как минимум сократится кол-во серверов. А вообще надо сначала определиться с топологией связей между площадками. Либо весь трафик между ними ходит через центральный офис (неполная связность - меньше работы по настройке), либо каждая должна быть связана с каждой (полная - больше). Зависит от ваших задач. Должны ли, например, филиалы иметь возможность общаться между собой, когда центральный офис в офлайне? Какие провайдерские сети лежат под туннелями и как они связаны? У вас вон, судя по скринам, оба филиала подключены к одному провайдеру. Стоит ли дублировать связь между ними, иными словами что вероятнее, что у этого провайдера аплинк упадет, или что внутренняя связность нарушится?
2. Трассируйте не с pfSense первого филиала, а с машины из его локальной сети. Второй филиал знает только про 172.11(кстати, почему 11 а не 16?).11.0/24 и ничего не знает про 10.0.5.2. Соответственно, не знает куда слать ответы и шлет их на шлюз по умолчанию, т.е. провайдеру.
3. Опять же в режиме PKI можно настройками на сервере передать клиенту нужные маршруты или даже завернуть весь трафик клиента через сервер.
-
1. Буду пробовать PKI. Связь нужна с центральным, возможность общаться между филиалами - приятная опция. В приведенных примерах тестовый вариант. Так сказать изучаю вопрос в боевых условиях. Вторые аплинки у филиалов и центра будут иными провайдерами или GSM.
2. Так в том то и дело, что трассировка с компа в сети филиала 1 на комп в сети филиала 2 - сразу же уходит к провайдеру, в то время, как трассировка с этого же компа на ком в сети центрального офиса - идет до адресата правильно. С компа центрального офиса, трассировка до компов филиалов тоже идет без нареканий.
По адресации - не совсем по rfc, понимаю. Но изменить пока возможности нет, но запланировано.И как филиал 2 должен узнать про туннель 10.0.5.0/24? В Вашей инструкции про это ничего не сказано. Как бы все само собой должно работать?
3. Понял.
-
Так в том то и дело, что трассировка с компа в сети филиала 1 на комп в сети филиала 2 - сразу же уходит к провайдеру, в то время, как трассировка с этого же компа на ком в сети центрального офиса - идет до адресата правильно. С компа центрального офиса, трассировка до компов филиалов тоже идет без нареканий.
По адресации - не совсем по rfc, понимаю. Но изменить пока возможности нет, но запланировано.Из чего видно, что трассировка уходит к провайдеру? На pfSense 1-го филиала настроен какой-нибудь policy routing? Приведите скрин Firewall -> Rules -> LAN и Floating если в последнем что-то есть.
-
Во всех трех PFS идентичные правила. На центральном только нет failover.
Каких то специальных правил не прописывал. Есть только портмаппинги по определенным портам, и все.
-
Выше правила FAILOVER сделайте правило:
- Lan Net * 172.11.10.0/24 * * none
-
Во втором филиале тоже:
- Lan Net * 172.11.11.0/24 * * none
-
Спасибо за хорошую инструкцию.
Все сделал как в первой публикации и заработало, НО не все получилось. Из филиала сеть главного офиса пингуется и полностью доступна, а из центрального офиса сеть филиала не видна. Пинг не идет даже до адреса 10.0.8.2 (виртуальный адрес филиала). Трейсроут доходит до pfsens-а главного офиса и теряется. Что это может быть? В какую сторону рыть? -
Спасибо за хорошую инструкцию.
Все сделал как в первой публикации и заработало, НО не все получилось. Из филиала сеть главного офиса пингуется и полностью доступна, а из центрального офиса сеть филиала не видна. Пинг не идет даже до адреса 10.0.8.2 (виртуальный адрес филиала). Трейсроут доходит до pfsens-а главного офиса и теряется. Что это может быть? В какую сторону рыть?Смотрите в сторону правил файервола на LAN центрального офиса. Простейший способ проверить, что дело в них - временно разрешить все.
-
Так в том то и дело, что в ЛАНе практически все разрешено, кроме 80 порта. Что б люди ходили через прокси, а не через NAT. В таблице маршрутизации тоже криминала не вижу. Грешу на обновление до версии 2.1. Похоже надо перебивать сервак, а очень не хочется.
-
2 swch
Покажите таблицу маршрутизации и что стоит на втором конце туннеля?
-
Сегодня выяснилась странная ситуация. Оказывается сеть главного офиса доступна, просто пинг не ходит. Но правила блокирующего протокол ICMP я не создавал. Чертовщина какая-то!
Вопрос закрыт. -
Попробуй прописать основной шлюз pfsense, на той тачке которую хочешь пингануть.
-
Пока объяснял уже сам все понял. Дела… Сегодня заставил наконец бегать OSPF по OpenVPN между работой и домашним микротиком. Полгода назад неделю на это убил безрезультатно. Пришлось править quagga_ospfd.inc
Спасибо за статью и ответы по теме.
В удаленном офисе появился появился микротик, хочется задействовать данную инструкцию, подключив микротик вместо pfsense в удаленном офисе (без OSPF)
Микротик будет находится за NAT.Отсюда вопросы.
1.Достаточно ли будет задействовать на микротике open-vpn клиент?
2. Если да, то как сказать микротикe пускать в локальную сеть за собой?
3.Где указать микротику использовать Shared key? -
http://nix.khd.ru/?p=1373
http://nixman.info/?p=1379
Ну и http://wiki.mikrotik.com/wiki/OpenVPN
P.s. Все таки это не профильный форум Микротика. И да, учитесь использовать поиск.