VPN-конь-тест

[vitus_wagner]

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

Поэтому предлагаю вниманию читателей несколько парочку нетривиальных ТЗ на конструкцию на базе OpenVPN,


Задача 1:

Имеется машина A, подключенная к локальной сети, для которой она является DHCP и DNS сервером, а также default gateway (используются ISC dhcpd и BIND). Имеется машина B, стоящая на хостинговой площадке у провайдера и работающая помимо всего прочего opevpn-сервером (для прочего на ней тоже есть bind). Удостоверяющий сервер, выписывающий сертификаты для клиентов OpenVPN-сервера B расположен на машине A.

Машина A практически постоянно поддерживает VPN соединение с машиной B. Канал широкий, безлимитный, но иногда падает (типичный мегаполисный броадбанд-провайдер).

Имеется несколько ноутбуков N₁, N₂, N₃...
которые могут подключаться либо в локальную сеть A, либо, подключившись к интернету через стороннего провайдера, устанавливать VPN-соединение с B.

Требуется обеспечить: чтобы независимо от того, как к данной конструкции подключен ноутбук N_i, он со всех прочих узлов этой сети (включая A, B и все N_j где i!=j) был виден под одним и тем же доменным именем (в домене, primary DNS которого расположен на A). А желательно, чтобы еще и под тем же IP-адресом.

В случае если канал между A и B лежит, в обоих половинках, на которые распалась сеть, все должны видеть друг друга под теми же именами (опционально адресами), включая те N_i, которые подключились после падения канала.

Желательно предложить решение не использующе TAP и режим server-bridge в OpenVPN.

Upd Конфигурация ноутбуков должна быть стандартная. Никакого софта кроме станадртного dhcp-клиента (кстати не всегда умеющего работать с client-id) и собствнено openvpn с файлами конфигурации (включая сертификаты) туда не ставится.


Призовая игра 1а:

Имеется еще и локальная сеть C, которая всем похожа на A, только канал от нее до B дорогой и неустойчивый (3G)

Требуется обеспечитьт чтобы N_i видели друг друга по тем же именам без гоняния всего траффика до B и обратно. И чтобы никаких действий по администрированию на C предпринимать не приходилось, она сама при появлении связи с B тащила все настройки с A.


Призовая игра 1б:
C - это не полноценный компьютер а точка доступа. Решение должно укладываться в ее маленькую флэш-память.



Задача 2
Имеется корпоративная сеть компании X, в котрую предоставляется openvpn-доступ сотрудникам. У компании X есть домены X.com Y.ru и Z.ru. Внутренние хосты локальной сети компании X имеют адреса в этих доменах. (без вынесения в отдельные поддомены). Естественно настроено так, что на внутренних DNS-серверах, в том числе и том, который отдается openvpn-клиентам, имена хостов локальной сети резолвятся (в серые IP), а внешние NS сервера этих доменов говорят "не знаю такого".

openvpn-сервер, через который можно попасть из дома в локальную сеть компании X, имеет доменное имя в одном из этих доменов (естественно, резолвящееся внешними DNS-серверами)

На машние А сотрудника данной компании установлен BIND. такой полноценный развестый bind, который обслуживает парочку известных всему интернету доменов, домен локальной квартирной сети в которую включена эта машина etc.

Требуется сочинить такие up- и down скрипты для openvpn, чтобы если openvpn- туннель в корпоративную сеть был поднят, пользовательские приложения на машине A резолвили внутренние хосты корпоративной сети. А если туннель опущен то выполнялся бы честный рекурсивный поиск по общедоступным серверам. Вносить какие-либо изменения в конфигурацию DNS серверов компании X и ее VPN-сервера, естественно, запрещено.

Имеется нескоько корпоративных сетей, которые могут подниматься и опускаться в произвольном порядке. Внутренние хосты всех функционирующих сетей должны резолвиться.

Comments

[tzirechnoy.livejournal.com]

Адрес, под которым должэн быть виден ноутбук, прописать ему статически на loopback. Ноутбуки перманентно подключить через OpenVPN к B. Повесить везде кваггу, пусть она через IBGP друг с другом объясняется и ковыряет таблицы роутинга A/B/ноутов, чтобы вычислить, через кого ближэ идти пакетам на этот ноут и обратно(OpenVPN B/direct A). Разумеется, OpenVPN-соединению сразу расстояние 2 выставить, чтобы если можно без него -- ходило без него.

PS на самом деле я не настоящий сварщик, BGP поднимал только один раз, притом это был EBGP, на цыске, и на самом деле не приходя в сознание (там от него ничего не нужно было по большому счёту). Возможно, что в данном случае хватит и какого-нибудь RIPD (хотя он по-моему с броадкастами, у меня от них всегда зубы болят). Или ospfd.

PPS Впрочем, quagga в OpenWRT занимает 70k, bgp к ней 275k, ospf 240k, rip 35k. Приемлемо, на мой взгляд, для точки доступа.

Да, задача 2 не имеет нормального решэния из-за кэша. Ненормальное -- это, например, приделать в качестве первого forwarders на адрес внутрикорпоративного dns-а (для требуемых доменов), вторым forwarders -- адрес сервера какого-нибудь гугля (можно ещё второй bind у себя жэ повесить на отдельном порту, если гуглю не доверяешь), iptables -j REJECT если пакет на такой адрес попытается выйти во внешний мир (чтобы DNS-сервер быстрее понимал, что надо идти на другие сервера, если роутинга во внутрикорпоративную сеть нет). Но с кэшом будет всё равно неприятно, хоть сбрасывай его по передёргиванию OpenVPNа.

[vitus_wagner]

По-моему, это заявка на диплом почетного гражданина города Вращенцы. А все потому что я не уточнил в условии, что на ноутбуки ничего ставить нельзя. Вся конфигурация должна быть на A, B и C.

Кстати, кэш - не проблема. Потому что никто не мешает из down-скрипта openvpn сделать очистуку кэша bind.

[tzirechnoy.livejournal.com]

Не надо почётного, я вид на жытельство хочу. А по делу -- как говорится, вперёд, устраивайте из анонсов dhcp новый протокол управления роутингом. Но диплом Вам выдадут таки первому.

[vitus_wagner]

У меня этот диплом уже больше 20 лет есть. Я их сам выписывал одно время. В смысле мэром числился.
Не будь я отцом-основателем этого славного города,
я не стал бы эти задачи вообще постить.

А тебе вообще диплом почетного гражданина 3-й степени положен. С правом несения Чуши. Потому что право нести чушь в моем журнале у тебя давно уже де-факто есть.

[tzirechnoy.livejournal.com]

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

[allter]

Интересно, а можно в схеме с демонами маршрутизации обойтись без явной таблицы маршрутизации на ноутах, т.е. установкой демонов только на A и C? Т.е. Ni будут получать свой ip в локалке через vpn-сервер на B или по dhcp от A/C, а демоны на A/C будут брать признак присутствия Ni в локалке по arp-кэшам, к примеру? Если перефразировать мой вопрос, то можно ли в демоны маршрутизации передавать данные о доступных локально хостах динамически?

[allter]

err: "можно ли обойтись установкой демонов только на A, B и C, т.е. на статические элементы инфраструктуры", конечно.

[tzirechnoy.livejournal.com]

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

[vitus_wagner]

Откуда у dhcp-клиента возьмутся маршруты, которые надо подчищать динамически? Сервер ему выдаст?
Если да, то конечно при перезапросе lease с сервера оно их почистит. Это если кто RFC не читал, более-менее штатная фича протокола.

Но вообще можно и нужно на мой взгляд обойтись без раздачи статически route на все dhcp-клиенты. Не люблю leases с expiration time в единцы секунд.

Я б лучше в сторону proxy-arp подумал.

[tzirechnoy.livejournal.com]

proxy-arp требует ethernetа, я как-то прикидывал -- получалось, что нужэн как минимум TAP межу A и B.

[vitus_wagner]

proxy-arp нам нужна в локальной сети A, Чтобы отправить на B по прописанному (только на нем) индивидуальному route те пакеты, которые предназначены для клиентов, подклченных к B.

А на B proxy-arp не нужен, поскольку VPN-соединения по определению точка-точка, и роутиться ВСЕ все равно будет через B. Поэтму там нужны индивидуальные маршруты для опять же клиентов B, а все остальное - чохом валить на A,

[avryabov.livejournal.com]

задача 1 - а чем не нравится tap и бриджевание?
Если я что-либо понимаю это как раз тот случай.
Впрочем tap я всегда использую, ибо с ним роутинг намного проще выходит.
Бриджевание пока не юзал.

1b - а openvpn клиент на С есть?

[vitus_wagner]

задача 1 - а чем не нравится tap и бриджевание?
Ску-у-чно. Нетривиальная задача сводится к примитивной задаче резервного DHCP-сервера на B, активируемого вотчдогом по потере видимости A.

Это же конь-тест. Вот и ставятся барьеры, как на скачках.


1b - а openvpn клиент на С есть?
Допустим, есть. Хотя на этом слабеньком MIPS-е тормозить же будет.

[avryabov.livejournal.com]

Может и скучно. Зато правильно.
Сомневаюсь в необходимости второго dhcp сервера, ибо openvpn сервер - вполне себе сам dhcp сервер. Надо будет прописать на A жесткую привязку ip по mac,
а на B ip по имени машины. И так, чтобы они совпадали.
к тому же бриджинг-то будет на клиенте А. (если я хоть что-то в нем понимаю.)

1b - ну если есть, то какая разница по сравнению с первым случаем?

[vitus_wagner]

Eсли использовать openvpn в режиме server-bridge, то openvpn будет работать этаким виртуальным эзернетом. И никаких IP-адресов клиентам выдавать не будет. Поэтому потребуется dhcp-сервер на B.

При этом бриджинг локальной сети на A и openvpn-сети в которой A является клиентом, на A придется организовывать дополнительно.

Требуется ведь не только адреса раздать, а еще чтобы по ним отвечали. Соответственно arp-запрос от клиента локальнйо сети A должен долетать до клиента openvpn-сети B.

А у 1a c 1b разница в том, что во втором случае там dns-сервер не bind и dhcp-сервер не ISC. Что несколько связывает руки конфигурирующему.

[avryabov.livejournal.com]

почитал малость про бриджинг.
server-bridge нафиг не нужен, ибо на B нету разделяемого эзернета. (a B у нас как раз сервер) достаточно tap и client-to-client
A вот на А надо будет запустить бридж ручками между эзернетом и tap, после подъёма openvpn.

[vitus_wagner]

Да, все правильно. server bridge это из варианта когда A и B совмещены на одной машине.

Только не ручками, а из up-скрипта.

[avryabov.livejournal.com]

Только не ручками, а из up-скрипта.
Да, именно. Я имел в виду что не командами openvpn, а внешними командами.
А настройка DHCP на А и раздача адресов на B openvpn сервером таки сохраняется.

[avryabov.livejournal.com]

по первой задаче: если ip сохранем у ноута - то только через TAP
если не сохраняем, то придется на ходу dns править когда к openvpn клиент цепляется.
в общем оба пункта "желательно" выполнить нельзя.

[vitus_wagner]

Почему только через TAP? сэр не в курсе о существовании proxy arp и route на отдельные хосты? Ну то есть с vpn-конца там вообще все просто должно быть сlient-to-client прекрасно знает какие у него IP-адреса есть, а общий роутинг на содержащую их сетдку идет на A.

DNS на ходу править, так же как на ходу править таблицу роутинга - не проблема совершенно. Для этой цели у openvpn --client-connect скрипт предусмотрен. У dhcpd со скриптами по-моему, сложнее, но задача тем не менее решаемая.

[avryabov.livejournal.com]

сэр не в курсе о существовании proxy arp и route на отдельные хосты?
proxy arp - не в курсе.
Месье знает толк в извращениях.
По логике - тот же бриджинг выходит, но _гораздо_ более сложный.
Возможностей ошибиться - куча.

[tzirechnoy.livejournal.com]

А чем здесь вообще поможэт tap и бриджэвание? Ну то есть есть пакет на ноутбуке N1 -- как этот N1 поймёт, пихать его в виртуальный ethernet-OpenVPN на B или в свою локалку?

[vitus_wagner]

Если оно все сбриджевано в один общий сегмент, то оно пошлет arp-пакет, который дойдет до того ноутбука, и получит от него ответ.

[tzirechnoy.livejournal.com]

Если оно сбриджёвано в общий сегмент, то у того ноутбука будет торчать два ethernetа в одном сегменте. Вы уверены, что хотите продолжать?

Ладно, продолжым. После этого во-первых, весь бродкаст трафик локалки точки A будет литься в каждый B-OpenVPN (включая тех несчастных, которые сидят в Маниле через роуминг, ха-ха).
Во-вторых, реальный путь пакета будет зависеть от погоды на марсе. Точнее, конечно, во-первых от скорости и потерь пакетов в каждой сетке -- но во-вторых от устаревания MAC-кэшэй тех линуксовых бриджэй. Так что с большой вероятностью пакеты между двумя ноутбуками в соседних комнатах с гигабитными портами будут бегать аккурат через пол-интэрнета от A до B.

Ну, и в-третьих, тебе придётся всё локалку на точке А пихать в один сегмент. Если там 5 розеток -- то это нормально. Если 40 и некоторое количество тупых D-linkов -- то это практически гарантия ежэгодного праздника «ищем кольца».

[vitus_wagner]

Если оно сбриджёвано в общий сегмент, то у того ноутбука будет торчать два ethernetа в одном сегменте. Вы уверены, что хотите продолжать?
С какой стати у ноутбука будут торчать два езернета в одном сегменте?
Если ноутбук в локальной сети, то у него есть только один езернет.
Если ноутбук подключился через стороннего провайдера, то эзернет у него в сегменте того провайдера (если там не ppp), а в рассматриваемом нами сегменте у него tap, предоставленный openvpn.

После этого во-первых, весь бродкаст трафик локалки точки A будет литься в каждый B-OpenVPN (включая тех несчастных, которые сидят в Маниле через роуминг, ха-ха).
Вот поэтому я и не хочу рассматривать решения с бриджом. Хотя, собственно, откуда у меня в сети broadcast-траффик, кроме arp?
Во-вторых, реальный путь пакета будет зависеть от погоды на марсе. Точнее, конечно, во-первых от скорости и потерь пакетов в каждой сетке -- но во-вторых от устаревания MAC-кэшэй тех линуксовых бриджэй.
Ну, не думаю, чтобы это было критично. Насколько я помню кэши тех бриджей устаревают как бы не за единицы минут. А времени чтобы оторвать ноутбук от сети, доехать с ним в осмысленное место, подключиться там к провайдеру и поднять vpn, потребуется явно больше.

Если там 5 розеток -- то это нормально. Если 40 и некоторое количество тупых D-linkов -- то это практически гарантия ежэгодного праздника «ищем кольца».
Там пять розеток и тупой D-link DIR-300, их соединяющий.

[tzirechnoy.livejournal.com]

>Если ноутбук в локальной сети, то у него есть только один
> езернет.

А куда у него денется ethernet, который предоставил ему OpenVPN?

[vitus_wagner]

А если ноутбук в локальной сети, то OpenVPN на нем не будет запущен.

[tzirechnoy.livejournal.com]

Кстати, предыдущий ответ я написал как-то неподумав. Поскольку более правильным было бы задать всё тот жэ вопрос:

>есть пакет на ноутбуке N1 -- как этот N1 поймёт, пихать его в
> виртуальный ethernet-OpenVPN на B или в свою локалку?

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

Так куда пойдёт arp-пакет?

Или Вы и OpenVPN на ноутбуке засунули в один бридж с Ethernet? Ну, тогда, натурально, удачи -- во-первых, без STP такое количество колец работать не будет вообще, во-вторых роутингом по факту займёся именно STP из линуксового ядра, а в-третьих, как (с какой скоростью и какой вменяемостью) STP занимается роутингом Вам предстоит узнать на практике. Будет весело, я гарантирую.

[vitus_wagner]

Рация - на бронепоезде. Ноутбук либо в локалке (любой из двух в варианте 1а и 1б), либо поднят VPN, если мы уже в локалке, то нахрена нам VPN?

[tzirechnoy.livejournal.com]

>если мы уже в локалке, то нахрена нам VPN?

Что значит нахрена? А куда он денется-то? Вы его что, руками выключать собрались?

Не, тогда конечно всё элементарно -- а заодно можно ещё всяких скриптов для ручного подключения/отключения к локалке написать. Какая разница, запускать sudo /etc/init.d/openvpn stop или sudo ~/locip.sh. Но от Вас я такого не ожыдал.

[vitus_wagner]

1. При покладании физического подключения к сети можно vpn и положить.
2. Поднимать его можно и автоматически, обнаружив что у нас поднялся сетевой интерфейс, а вот адрес нам на него выдали не то, который наш любимый.
3. При подключении из нештатных мест лучше поднимать openvpn руками и только если надо. А то вдруг это GPRS в роуминге по 25 рублей 20 килобайт.

[captain-hell.livejournal.com]

Очень просто. Всегда подключать узлы через openvpn. Всегда маршрутизировать через openvpn.

Второе. Настроить себя кеширующим DNS корподнсов. Использовать свой днс. Не вижу проблем в том, что в некоторое время хост в X будет резолвится, но не будет маршрутизироваться...

[vitus_wagner]

1. И через что будет ходить эта самая openvpn в случае подключения по локальной сети?

2. И что будет если админы корпорации поменяют адрес vpn-сервера? Узнать-то новый адрес можно только из публичного DNS того домена, для которого мы себя объявили кэширующим DNS, и мы помним старый адрес.

[captain-hell.livejournal.com]

1. через локальную сеть? в чем проблема?
2. для vpnserver можно использовать другой днс, например.

[vitus_wagner]

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

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

2. Для vpnserverа нельзя использоватьболее другой DNS.
Потому что устройство корпоративной сети по условиям задачи менять нельзя.

[captain-hell.livejournal.com]

Я не выключаю опенвпны на своих девайсах. В домашней сети пакеты сами завернутся на локалку, минуя ethernet.

Езернет не вдвое быстрее вайфая, а вдесятеро...

[vitus_wagner]

Я уже понял, что вы самовлюбленный идиот, не умеющий читать условия задачи, а желающий вместо того, чтобы решать поставленную задачу похвастаться тем, что умеет (а не умеет примерно ничего)

Еще раз увижу - забаню.

[avryabov.livejournal.com]

1. эти пакеты чтобы добраться с одного до другого ноута в пределах локалки сначала зашифруются в ovpn на ноуте N1,
потом по локалке пойдут до A,
(шифруются еще раз???)
пойдут до сервере B
там дешифруются (2 раза???) и снова шифруются (2 раза???)
пойдут на A,
(дешифруются ???)
потом на ноут N2
и еще раз дешифруются.

И трафик дикий по каналу A-B, и куча перешифровок которые вообще не нужны.

[vitus_wagner]

Думаю, что лишних перешифровок все же не будет (если не считать того, что в локалке шифрование вообще лишнее). Потому что ноутбук будет из локалки устанавливать VPN-соединение с B по его публичному а не VPN-овскому адресу.

А VPN-адрес A будет использоваться только для хождения непосредственно на A (через B, с ноутбука, который к этому A физически подклчюен).

[begemotv2718.livejournal.com]

Ну, может тогда попробовать #include в named.conf файл, в котором мы внешним скриптом прописываем форвардеры когда поднимаем vpn? C последующим rndc reload? Если я, конечно, еще правильно помню, что делает rndc reload

[vitus_wagner]

Да в общем-то можно и service bind9 restart, если reload не поможет.

[avnik.livejournal.com]

Кстати еще задача для "призовой игры"

Есть ноутбук в квартире у которого
1 есть ethernet, который мы считаем безопасным.
2 есть wifi который мы не считаем безопасным, и гоняем поверх него openvpn

Остальное как в задаче выше -- прозрачный доступ, и желательно прозрачное же переключение -- я не хочу чтобы у меня X приложение схлопнулось от того что я выдернул ethernet.