OpenVPN PSK: Site-to-Site инструкция для обсуждения
-
Провайдер подкинул еще одну делему.
Дело в том, что он мне назначил для точки подключения 1 адрес 10.1.1.0/30. То есть их порт будет занимать 10.1.1.1/30 и далее мой серв с впн 10.1.1.2/30. Во второй точке они мне назначили 10.1.2.0/30 то есть 10.1.2.1/30 это их порт и 10.1.2.2/30 это клиентская моя коробка с сенсом. Кто о опыту скажет как быть? А то ездить между филиалами не айс(
Хороо бы это в ман добавить а то елеком так всех подключаетЯ сделал так:
На сервере
Ну а на клиенте гейт 10.10.2.1/30 и роутинг до 10.10.1.0/30 через него.
пингует с 10.10.1.2/30 порт на другой стороне 10.10.2.1/30, поидее все должно быть нормально?
Вобщем ничего не работает. Понять не могу. Логи заканчиваются на том что опен правильно определил локал и ремоут и все. Через пинг пиршуется удаленный порт, сам сенс не пингуется… -
Почему в тексте 10.1.1.0/30, а на скринах 10.10.1.1?
-
Почему в тексте 10.1.1.0/30, а на скринах 10.10.1.1?
10.10 правильно
Вобщем в чем состоит дело. Все было настроено на 10.1.1.0/30.
Потом пров сделал так:
в офисе 1 он назначил подсеть 10.10.1.0/30, то есть 10.10.1.1/30 это порт а 10.10.1.2/30 это сенс сервер впн.
в офисе 2 он назначил подсеть 10.10.2.0/30, то есть 10.10.2.1/30 это порт а 10.10.2.2/30 это сенс клиент впн.
Я прописал роутинги как описано выше.
Картина такая:
На сервере (10.10.1.2/30) я могу пингануть 10.10.2.1/30. При этом 10.10.1.1/30 не пингуется
На клиенте (10.10.2.2/30) я могу пинговать 10.10.2.1/30 и 10.10.1.1/30, не пингуется 10.10.1.2.
Не могу понять почему не пингуется сам порт 10.10.1.1/30 с сервера 10.10.1.2/30…
Мне кажется что нат режет трафик. А может и нет.
Лог ВПН с клиента:Feb 18 19:23:29 openvpn[22850]: UDPv4 link local (bound): [AF_INET]10.10.2.2 Feb 18 19:23:29 openvpn[22850]: UDPv4 link remote: [AF_INET]10.10.1.2:1194 Feb 18 19:23:29 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:23:29 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:23:30 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:23:31 openvpn[22850]: write UDPv4: No route to host (code=65) Feb 18 19:24:29 openvpn[22850]: Inactivity timeout (--ping-restart), restarting Feb 18 19:24:29 openvpn[22850]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 19:24:31 openvpn[22850]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 18 19:24:31 openvpn[22850]: Re-using pre-shared static key Feb 18 19:24:31 openvpn[22850]: Preserving previous TUN/TAP instance: ovpnc1 Feb 18 19:24:31 openvpn[22850]: UDPv4 link local (bound): [AF_INET]10.10.2.2 Feb 18 19:24:31 openvpn[22850]: UDPv4 link remote: [AF_INET]10.10.1.2:1194
-
Хорошая инструкция. Было бы неплохо нарисовать ещё мануал IP2IP+IPSec, как более орднунг.
Не рекомендуют разработчики использовать IPSEC, если OpenVPN поддерживается на обеими соединяемыми сторонами. Впрочем, GRE/GIF over IPSEC + OSPF я настроил, хотя и не без плясок с бубном))
-
Не рекомендуют разработчики использовать IPSEC
Разработчики чего? Сенса, IPSec'a, OpenVPN'a? А то, что переход с openvpn на ipsec даёт значительное снижение нагрузки на маршрутизатор и нехилое увеличение скорости соединения про это разработчики "забыли"? А может вообще не знают? Кароче, меньше слушать надо таких разработчиков. :D
-
Не рекомендуют разработчики использовать IPSEC
Разработчики чего? Сенса, IPSec'a, OpenVPN'a? А то, что переход с openvpn на ipsec даёт значительное снижение нагрузки на маршрутизатор и нехилое увеличение скорости соединения про это разработчики "забыли"? А может вообще не знают? Кароче, меньше слушать надо таких разработчиков. :D
Разработчики pfSens'a конечно, здесь мы вроде как его обсуждаем, но вам безусловно виднее))
http://forum.pfsense.org/index.php/topic,51551.0.html -
Небольшое замечание по настройке OSPF. Не надо делать как на картинках выше. Во-первых, в пакет Quagga OSPF сейчас добрые люди прислали коммит, который не дает сервису OSPFd запустится, если у вас что-то прописано в Disable Redistribution. Во-вторых, даже если это починят, прописывать туда что-либо нет нужды и вообще неправильно.
Т.е. в Global Settings снимаем галку с Redistribute connected subnets и вычищаем все Disable Redistribution. Идем на вкладку Interface Settings и добавляем там наш LAN интерфейс, в настройках которого ставим галку Interface is Passive.
Этого достаточно для того, чтобы соседи по OSPF узнали маршрут в вашу локальную сеть, и такая настройка более лучше соответствует принципам OSPF. -
Сети для самых маленьких. Часть седьмая. VPN
http://linkmeup.ru/blog/50.html -
Сети для самых маленьких. Часть седьмая. VPN
Дельная ссылка, спасибо.
-
Ребята, помогите плз…чего-то я вообще не пойму что происходит, ни при каких вариантах...
Что имеем:
1. Шлюз_1
WAN: 94.27.XX.X1/29
LAN: 192.168.2.0/24
2. Шлюз_2
WAN: 94.27.XX.X2/29
LAN: 192.168.3.0/24
Оба шлюза стоят рядышком и подключены в тупой свитч от одного провайдера.
На обоих стоит пакет Quagga OSPF и настроено согласно картинок выше. OSFP поднимается, все замечательно, а попингуя нет и доступа между сетями тоже, и в чем причина никак не могу понять!!!
В фаерволе разрешил WAN подсети ходить как угодно и куда угодно, так же добавил правило для локальных сетей, снял галочки на в настройках WAN интерфейса "Block private networks" и "Block bogon networks". Где гоню, подскажите пожалуйста.
HELP ME PLEASE!!! А то скоро шарики за ролики заедут совсем... :( -
Здравствуйте, настроил между головным офисом и тремя филиалами туннели без динамической маршрутизации пока, все три туннеля поднялись, но с третьим проблема,
головной офис - LAN IP 192.168.9.1/24 Tunnel IP 10.0.6.1
филиал - LAN IP 192.168.7.1/24 Tunnel IP 10.0.6.2
из локальной сети филиала головной офис не пинугеться и на оборот, НО если это делать через терминал на шлюзах то всё пинугеться.
так же из локальной сети пингуются туннельные адреса 10.0.6.1 и 10.0.6.2 и из филиала и из головного офиса.
Правило в фаерволе для интерфейса OPENVPN - разрешёно всё, на обеих шлюзах.
Т.е. на двух предыдущих туннелях сделано один в один, там всё номрально, тут вот такая ерунда.
маршруты:
-
Настроено 2 канала OpenVPN (site-to-site, shared key), маршрутизация по OSPF. В общем все сделано, как у вас здесь написано. Нарисовалась проблема, при падению 1 из каналов интернета, соответственно падает туннель опенвпн. Ospf в соотвествии с метриками перекидывает все на другой канал опенвпн. Но вот при появлении интернета, туннель не восстанавливается. В логах пишется вот такая ошибка и служба openvpn падает. Перезапуск не помогает, светится такая же ошибка.
Aug 19 11:28:58 openvpn[48699]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 Aug 19 11:28:58 openvpn[48699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 19 11:28:58 openvpn[48699]: LZO compression initialized Aug 19 11:28:58 openvpn[48699]: TUN/TAP device /dev/tun2 opened Aug 19 11:28:58 openvpn[48699]: /sbin/ifconfig ovpns2 172.17.1.1 172.17.1.2 mtu 1500 netmask 255.255.255.255 up Aug 19 11:28:58 openvpn[48699]: FreeBSD ifconfig failed: external program exited with error status: 1 Aug 19 11:28:58 openvpn[48699]: Exiting
Помогает перезапуск службы Quagga OSPFd. После этого служба Openvpn стартует и все работает.
-
Что-то похожее :
1. http://lists.freebsd.org/pipermail/freebsd-current/2009-July/010020.html
Как вариант, если возможно, использовать tap-адаптер вместо tun2. http://www.daemonforums.org/showthread.php?t=527&highlight=hostname
Смотрите внимательно конфиг. Красным в его конфиге сервера выделено dev tun0, т.е. явно указан номер tun-интерфейса. -
Настроено 2 канала OpenVPN (site-to-site, shared key), маршрутизация по OSPF. В общем все сделано, как у вас здесь написано. Нарисовалась проблема, при падению 1 из каналов интернета, соответственно падает туннель опенвпн. Ospf в соотвествии с метриками перекидывает все на другой канал опенвпн. Но вот при появлении интернета, туннель не восстанавливается. В логах пишется вот такая ошибка и служба openvpn падает. Перезапуск не помогает, светится такая же ошибка.
Aug 19 11:28:58 openvpn[48699]: OpenVPN 2.2.2 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] built on Apr 2 2013 Aug 19 11:28:58 openvpn[48699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 19 11:28:58 openvpn[48699]: LZO compression initialized Aug 19 11:28:58 openvpn[48699]: TUN/TAP device /dev/tun2 opened Aug 19 11:28:58 openvpn[48699]: /sbin/ifconfig ovpns2 172.17.1.1 172.17.1.2 mtu 1500 netmask 255.255.255.255 up Aug 19 11:28:58 openvpn[48699]: FreeBSD ifconfig failed: external program exited with error status: 1 Aug 19 11:28:58 openvpn[48699]: Exiting
Помогает перезапуск службы Quagga OSPFd. После этого служба Openvpn стартует и все работает.
Это читали?
Небольшое замечание по настройке OSPF. Не надо делать как на картинках выше. Во-первых, в пакет Quagga OSPF сейчас добрые люди прислали коммит, который не дает сервису OSPFd запустится, если у вас что-то прописано в Disable Redistribution. Во-вторых, даже если это починят, прописывать туда что-либо нет нужды и вообще неправильно.
Т.е. в Global Settings снимаем галку с Redistribute connected subnets и вычищаем все Disable Redistribution. Идем на вкладку Interface Settings и добавляем там наш LAN интерфейс, в настройках которого ставим галку Interface is Passive.
Этого достаточно для того, чтобы соседи по OSPF узнали маршрут в вашу локальную сеть, и такая настройка более лучше соответствует принципам OSPF.Если да, то конфиг Quagga и таблицу маршрутов на момент, когда один канал VPN лежит, приведите.
-
Да, именно так и делал. 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 (ноутбуки, телефоны и т.п.)