OSPF через OpenVPN, когда одна сторона за NAT'ом

OpenVPN в режиме P2M с OSPF не дружит, я уже натрахался в своё время с этим. Работает, но как-то криво. Перешёл на P2P - проблем нет.

как соединить два OpenVPN сервера точка-точка, если одна из сторон за NAT'ом?

А в чём проблема, собсно? У меня половина клиентов в P2P за натом, проблем нет.

Сервер что-то вроде:

dev tap2
proto udp
port 1195
topology subnet

mlock
nice -19
fast-io

ifconfig 192.168.254.25 255.255.255.252

mtu-disc maybe

keepalive 10 120

secret /etc/openvpn/ssl/openvpn.key

auth SHA1
cipher BF-CBC

user root
group root

persist-key
persist-tun

verb 3

Клиент:

dev tap0
nobind
remote server 1195
proto udp
topology subnet

mlock
nice -19
fast-io

ifconfig 192.168.254.26 255.255.255.252

mtu-disc maybe

keepalive 10 120

secret openvpn.key

auth SHA1
cipher BF-CBC

user root
group root

persist-key
persist-tun

verb 3

а можт легче ipsec, gre и мозг себе не грузить?

там вроде проблема в том, что ospf использует broadcast сообщения, а openvpn их как раз не поддерживает.

В ospf есть point-to-point, есть non-broadcast и куча всего.

Что-то типа:

interface lan1
 ip ospf network non-broadcast

router ospf
 neighbor 192.168.21.133

как давно появилось? у меня 12 лет назад на зебре была проблема с openvpn, что оно никак не работало. после этого уже не работал с сетями в таком масштабе как раньше.

Не легче. Если бы не было НАТа, то да. А вот с натом GRE работать уже не будет, ему нужен чёткий адрес пира. Для этого нужен NHRP + mGRE, а это уже геморрой.

OpenVPN поддерживает всё что нужно, особенно в tap-режиме, там просто обычный ethernet со всеми его фичами. Ну и OSPF да, поддерживает и работу в PtP как уже указали.

Спасибо! Это помогло поднять OpenVPN точка-точка с клиентом за NAT.

Кстати я раньше даже и не пробовал не использовать X.509 авторизацию, так как это не секьюрно, но зато коннект почти мгновенно проходит, при использовании X.509 + tls у меня секунд 5 минимум уходит причем на проблемном канале с потерями пакетов tls постоянно ругается и канал рвёт.

OpenVPN p2p успешно поднялся, причем у меня tun интерфейс. C OSPF никаких совершенно проблем:

interface tun30
     ip ospf network point-to-point

router ospf
     ospf router-id 1.2.2.6
     network 192.168.254.0/24 area 0

Причём neighbor указывать не обязательно, ip ospf network non-broadcast тоже не обязательно, broadcast вполне успешно через tun ходит вот proof:

tcpdump -ni tun30 proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun30, link-type RAW (Raw IP), capture size 262144 bytes
02:33:27.035727 IP 192.168.254.25 > 224.0.0.5: OSPFv2, Hello, length 48
02:33:27.201675 IP 192.168.254.26 > 224.0.0.5: OSPFv2, Hello, length 48

Кстати я раньше даже и не пробовал не использовать X.509 авторизацию, так как это не секьюрно

Ну, это несекурно, в общем и целом, только с точки зрения Forward Secrecy, то бишь возможности расшифровки всего уже прошедшего траффика получив ключ. В TLS же применяются сессионные ключи, которые меняются периодически. Мне лично и такой безопасности достаточно.

при использовании X.509 + tls у меня секунд 5 минимум уходит причем на проблемном канале с потерями пакетов tls постоянно ругается и канал рвёт

Угу, та же фигня. Из-за этого в т.ч. и отказался от него. Особенно со всякими 3G проблемы.

А вот с натом GRE работать уже не будет, ему нужен чёткий адрес пира

с фига ли, я ж про GRE over IPsec, а не IPsec over GRE. создаешь пару подсетей/хостов на loopback, между ними кидаешь ipsec (initiator тот кто за натом, разумеется), loopback-сети видят друг друга, через них перекидываешь ospf. Работает как минимум на hp и на микротиках, уверен что на других девайсах тоже выполнимо

IPsec может поднять туннель когда одна сторона за sNAT?

Да.

да, может, но инициатор соединения должен быть тот, кто за натом (ясно что в провайдерский шлюз долбиться бесполезно), и это добро не должно быть заблочено на уровне провайдера.

В плане - ты же можешь поднять скажем ssh-клиента из-за ната. Или pptp-клиент. Или любое другое клиентское соединение. Но с серверным выйдет шляпа. Та же фигня

и это добро не должно быть заблочено на уровне провайдера

Лично не сталкивался с таким, на мобильном нормально работает, у проводных тем более.

бывает, видел как минимум у себя в универе. Еще помню на лоре кто-то ныл что кто-то из крупных московских провайдеров борзел и закрывал все подряд. Но это редко, да

Например в Китае IPsec, L2TP, GRE, PPtP, OpenVPN если и не блокирутся полностью но потери пакетов и ограничение скорости гарантировано, причем если фиксируется на какой удалённый IP был установлен VPN то любой трафик до этого IP лагать будет, даже icmp...

Ну если такие примеры, то тогда уж в КНДР лагает еще сильнее :)

У меня такая схема:

OpenvVPN2_server1 -> OpenVPN1_server1 -> PPPoE_server1 -> OpenVPN1_Server2 -> OpenVPN2_Server3

Т.е. OpenVPN1 поднимается через PPPoE до VPN провайдера (Server2), затем через OpenVPN1 я поднимаю OpenVPN2 до своего сервера уже.

MTU PPPoE интерфейса 1492 На OpenVPN1 (до VPN провайдера) выставлено:

--mssfix 1400
--rcvbuf 1048576 (приходит по push)
--sndbuf 524288 (приходит по push)
--txqueuelen 100

Я уже замучался с подбором параметров канала для OpenVPN2 который поднимается через OpenVPN1, как настроено сейчас:

--fragment 1300 
--mssfix 1200 
--replay-window 256 60 
--sndbuf 393216 
--rcvbuf 393216 
--txqueuelen 1000 
--fast-io

Подскажите, как правильно настроить OpenVPN через OpenVPN, или может IPsec в данном случае будет лучше?

P.S. сразу отвечу на возможный вопрос, VPN провайдера из данной схемы нельзя выкинуть

что за оборудование? чисто линуксовые гейты или что-то более фирменное?

Ubuntu на моих серверах

ну, тогда тут помочь кроме как показать на маны не могу, у меня были hp, микротики, стоунгейты и всякое говно (даже марку вспоминать не хочу).

Но имхо в общем случае если у openvpn есть проблемы с gre и ospf - переключаешься на ipsec и просто вешаешь цепочку тоннелей через loopback-адреса.

Логика будет примерно такая: IPsec с двумя lo в качестве remote private addr (через внешку, инициатор за натом) -> GRE с еще один lo (через lo от пиписека) -> OSPF между lo от GRE и в ту же зону пихаем все что нужно раздавать. Да, часто можно выкинуть пару lo из этой модели, но так имхо более четко видно где и через какой тоннель кто ходит

На каждом этапе проверяешь что каждый новый тоннель видит lo другого сервера.

И да, если прибежит сюда кто-то с воплями «нафига так сложно, нафига все lo, ведь на $brandname...» - ответ очень простой: lo и p2p тоннель это самые базовые функции, которые поддерживает 90% оборудования (остальные 10% лучше закопать сразу). Потому хоть ты связываешь две циски, хоть циску и линух, хоть hp и микротик (тот еще секс) - в таком формате они все точно найдут общий язык, да и влепить в эту цепочку девайс, который скажем не умеет ospf (только net2net ipsec) довольно легко. Когда оборудование более-менее одинаковое - можно идти куда более короткой дорогой

Интересует мнение того кто поднимал туннель в туннели (у меня получается 3 вложенности). Что делать с MTU (у OpenVPN очень много настроек MTU, есть --tun-mtu, --link-mtu, --fragment, --mssfix так же на скорость влияют --txqueuelen, --fast-io, --sndbuf, --rcvbuf, --replay-window), про всё это я знаю и пробовал крутить с разными значениями и ничего толком не помогает. Говорим про UDP режим.

Под «не помогает» я подразумеваю что скорость OpenVPN ниже скорости OpenVPN туннеля предыдущего вложения. Хочется выжить максимум.

Опять же, если поднимать IPsec сквозь OpenVPN, какие там заморочки с MTU и иже с ним?

А можно попросить показать рабочий конфиг для соединения 2х серверов чере GRE over IPSec (одна сторона за sNAT), желательно на базе OpenSWAN, большое спасибо за ранее.

Под «не помогает» я подразумеваю что скорость OpenVPN ниже скорости OpenVPN туннеля предыдущего вложения. Хочется выжить максимум.

Как предположение, железка не справляется.

SHA1 + BF-CBC = CPU 3% max

скорость вложенного тоннеля равная скорости первого логически невозможна. А про вложенный опенвпн тут народ часто ноет, именно что падение скорости 100 на 20. Про пиписек - хз, у нас с этим проблем не возникало, но тоже разумеется скорость ниже прямого подключения.

Про заморочки с mtu сказать ничего не могу ибо от опенвпн вообще стараюсь держаться далеко, ну его нахрен, тут я хоть знаю как должен каждый шаг каждой фазы приветствия выглядеть, а чего там нового наворотили...

Про рабочий конфиг - у меня есть рабочий конфиг такой связки для Mikrotik + HP MSR20-21, с серверами нету, сорри. На хабре вроде что-то было. Для нат разницы быть не должно - указываешь внешний адрес, а с другой стороны один фиг подключиться не сможешь, инициатор все равно внутренний будет

Моя задача усложнилась, у VPN провайдера обнаружилась странная политика, при сильном потоке траффика через канал (100mbps на протяжении 5 минут например) блокируются все порты кроме 22, 53, 80, 443. Наверное с торрентами борются, что бы свои сервера не перегружать, траффик у меня через их VPN безлимитный.

OpenVPN в udp через Socks5 на tcp 22 спас ситуацию, и даже скорость чутка поднялась до 30Mbps. В это же время качаю торрент напрямую через Socks5 и торрент на скорости 100Mbps спокойно качается. Причем Socks5 шифрует траффик camellia-256-CBC, это про нехватку ресурсов, ресурсов CPU хватает однозначно.

От сюда вопрос, а IPSec умеет через proxy работать? И по прежнему вопрос открытый, какие оптимальные настройки для OpenVPN вложенного в другой OpenVPN.

А зачем тебе прокси? Если они тупо порты режут - ну выставь другие порты (на худой конец pre и postrouting тебя спасут).

А вообще такого провайдера в жопу слать надо. Но реально безлимитных инетов не бывает, это факт.

Где собака зарыта не понятно, но при соединении через прокси OpenVPN в итоге с 20Mbps разогнался до 50Mbps (и это не совпадение, при отключении прокси стабильно до 20Mbps падает).

(на худой конец pre и postrouting тебя спасут)

а можно по подробнее, что имеется ввиду?
Послать VPN провайдера я не могу, только его VPN может DPI основного провайдера обойти, они используют свою сборку OpenVPN, которая умеет DPI обходить.

Кстати proxy (shadowsocks) еще умеет некоторые DPI обходить тоже, так что это ещё для маскировки OpenVPN. Но DPI основного (наземного) провайдера обойти крайне сложно, shadowsock раньше справлялся, пока проект не закрыли...

Ну в плане допустим у тебя забиты порты для иписека. Так как у тебя стоят линуксовые серваки, ты можешь сделать смену порта через тот же iptables, даже если софт умеет только один порт. В плане что пустить тоннель по другому порту ты всегда сможешь. Про скорость ничего сказать не могу, просто пробуй, поднять тоннель дело 20 минут.

Кстати про dpi - а что, просто шифруху провайдер режет??? О-о

Но реально безлимитных инетов не бывает, это факт.

4.2 Еще как бывает, только дорого.

Еще как бывает, только дорого.

это когда у тебя присутствие на эксчейндже есть? ну да, тогда анлим. Только офигительно дорого и хз зачем нужно если ты не провайдер

IPSec позже попробую. Пока поднял UDP OpenVPN через UDP Socks5 proxy (Shadowsoks). Такая конструкция полностью решила проблемы со скорость во вложенном OpenVPN, до 60Mbps получил, уперся в производительность CPU.
Официально VPN провайдер сказал, что он блокирует VPN на своей сети, дефакто палки в колёса вставляет а не блокирует.

Кстати про dpi - а что, просто шифруху провайдер режет??? О-о

https и ssh вроде как только в Иране режут. У меня DPI не режет шифрованный траффик, он только выдавливает заголовки VPN соединений и если такие находит то начинает им портить жизнь. Например OpenVPN запускается и живёт не более нескольких минут, после реконнекта опять можно соединиться но потери до 80% процентов сразу и 100% через пару минут и так далее. PPtP и IPSec сразу падают.
У меня есть пропретарный бинарник, доработанный OpenVPN, который может даже самый навороченный DPI обходить, если кому интересно могу дать поснифить, подизассемблить.

Да нет, обычные корпоративные тарифы с гарантированной скоростью. У МГТС даже в открытом доступе и типа для всех одинаковые. А так обычно они индивидуальные. В прошлом году подключали от пчелайна 50мбит за 45 в мес.

А в сторону softether не смотрели? Сразу скажу не пробовал, но читал что вроде он как раз не идентифицируется как vpn.

Официально VPN провайдер сказал, что он блокирует VPN на своей сети

это в договоре или это в тп ответили? если второе - шли их в хрен и долби их начальство по телефону пока они не согласятся что неправы. Если забанят номер - возьми ту же задарму, у них динамика. Нам приходилось доводить сначала техподдержку до слез, а потом еще и начальника участка до нервного срыва, когда кое-кто отказывался по договору все делать.

ну 45 это не дорого. Но провайдер провайдеру рознь - иногда они типа «корп безлимит», а потом начинают на говно исходить по любому поводу и без повода. У нас было из где-то 12-15 провайдеров около половины адекватных, еще несколько были так себе, два были совсем неадекваты и без возможности от этих говнарей отвязаться. Пришлось доводить их звонками на личные мобильники.

ну 45 это не дорого.

Как сказать у мгтс это 30.

Но провайдер провайдеру рознь - иногда они типа «корп безлимит», а потом начинают на говно исходить по любому поводу и без повода.

Про скорость волшебное слово «гарантированная», собстно и цены между «гарантированными» и «до» различаются в разы. Так что если подключали «гарантированную» скорость и обязательства не исполняются, провайдера сразу с говном мешать надо. А если есть альтернатива то просто сходу на север такого прова.

Как сказать у мгтс это 30.

мгтс

провайдер

да, сорри, забыл, у нас было не два, а три неадеквата. Их начальника участка тоже доводить пришлось

По поводу мгтс соглашусь на все 100, большего дибилизма я не встречал ни у одного из провов. Те не многие случаи общения с ними оставляли неизгладимые впечатления и какие-то странные ощущения, как в «лыжах на асфальте». Я не про ТП с этими слава богу пока еще не сталкивался :)

Те не многие случаи общения с ними

счастливый человек. Я помню как звонил им в тп, а они как раз юрлиц тоже на общую очередь перевесили в кц. «Время ожидания в очереди 33 минуты»... И главное я даж добавочный знаю - фиг, в общей очереди нельзя, сначала оператор должен в ручном режиме перекинуть в очередь где это разрешено

Начальник рассказывал про этих чертей много интересного: например в приемке работ со стороны тп нужна только (!) подпись сотрудника тп, подпись заказчика не нужна, потому они часто вообще не приезжают. А когда приезжают, начинают вонять что сип это типа шлак, и будущее за медью и гайками-барашками.

А в сторону softether не смотрели?

не слышал раньше, интересная штука, если сможет через Золой Щит пройти тогда цены ему не будет :)