OpenVPN PSK: Site-to-Site инструкция для обсуждения
-
Хорошая инструкция. Было бы неплохо нарисовать ещё мануал IP2IP+IPSec, как более орднунг.
-
Провайдер подкинул еще одну делему.
Дело в том, что он мне назначил для точки подключения 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 pppoe0172.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 pppoe0172.17.1.0/24 - сеть первого туннеля (ovpnc2), который упал. И больше не поднимается, как раз ошибка, как в посте выше.
А как конфиг просмотреть QUAGGA OSPFd?
/var/etc/quagga/ospfd.conf
проблема в этом маршруте:
172.17.1.2 172.17.2.1 UGH1 0 0 1500 ovpnc3quagga видит клиентский адрес упавшего туннеля через сервер и держит маршрут к нему в таблице,
соответственно 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 был маршрутом по умолчанию. Не понятно что за клиенты.
