Публичен префикс през OpenVPN: поправка на обратния път

Гледате как тунелът се вдига и клиентът пингва отсрещната страна, а после публичен адрес, който принадлежи зад VPN, отговаря от другаде или изобщо не отговаря. Този симптом обикновено няма нищо общо с шифъра или сертификатите. Префикс, маршрутизиран от доставчика, се доставя като IP маршрут и пренасянето му през OpenVPN означава възпроизвеждане на този маршрут на две нива и запазване на адреса на източника по обратния път. Мостово свързване на WAN не е необходимо, а добавянето на адреса към интерфейс не създава горния маршрут.

Префиксът първо трябва да бъде маршрутизиран към вас

Питайте доставчика как се доставя блокът. Префикс, маршрутизиран към основния адрес на вашия сървър, е друго нещо в сравнение с адреси, които доставчикът очаква да достигне директно в WAN сегмент. Само първият модел работи с дизайна тук.

Ако доставчикът маршрутизира 198.51.100.64/28 към входния ви сървър, пакетите за този диапазон пристигат на сървъра и спират там, освен ако не ги препращате. Ако вместо това доставчикът прави мост на диапазона към вашия uplink, сървърът трябва да отговаря на ARP за него, което е друг проблем.

Тествайте модела на доставяне, преди да пипате OpenVPN: отвън пингнете адрес в блока и вижте кой интерфейс го получава. Ако нищо не пристига, никаква конфигурация на тунела няма да помогне. Ако адресът отговаря директно в WAN, доставчикът прави мост, а не маршрутизира, и дизайнът по-долу не важи.

Две нива на маршрутизация: маршрут в ядрото и iroute

OpenVPN се нуждае от префикса на две места. Ядрото трябва да знае, че префиксът принадлежи на тунелното устройство, за да влизат препратените пакети в OpenVPN вместо в маршрута по подразбиране. OpenVPN също трябва да знае кой удостоверен клиент притежава префикса, а това е записът iroute в директорията за конкретния клиент.

Маршрутът от страна на сървъра изглежда така, като префиксът и маската трябва да съвпадат с разпределението:

ip route add 198.51.100.64/28 dev tun0

Конфигурацията за конкретния клиент задава собствеността. Поставете я във файла CCD, именуван по общото име на клиентския сертификат, и потвърдете, че точно тази директория сървърът действително чете:

iroute 198.51.100.64 255.255.255.240

Документацията на OpenVPN за маршрутизирани мрежи описва двете нива и защо са разделени. Маршрут в ядрото без iroute изпраща пакети в тунела без собственик и OpenVPN ги изхвърля. iroute без маршрута в ядрото оставя пакетите на пътя по подразбиране на сървъра. И двете грешки изглеждат от страна на клиента като счупен тунел.

Къде живее адресът на услугата

Делегираният префикс не е същото като собствените адреси на тунела. Номерирайте връзката от частното пространство, ако искате, и поставете публичния адрес на услугата там, където услугата действително работи.

На Linux клиент, който терминира услугата локално, е достатъчен един адрес на хост:

ip address add 198.51.100.70/32 dev lo

Ако префиксът се маршрутизира нататък към VM хост или друга LAN, конфигурирайте вместо това този път надолу и неговия обратен маршрут. Не е необходимо да се присвоява всеки адрес в блока на VPN клиента и това създава конфликти по-късно.

Запазете публичния източник по обратния път

Отговор от делегирания префикс трябва да излезе през тунела и да достигне маршрута на доставчика. Ако отдалеченият хост го изпрати през собствения си ISP, адресът на източника изглежда подправен и доставчикът или получателят го изхвърлят. Решението е правило, базирано на източника, или отделна таблица за маршрутизация, а не по-широк NAT. Без него услугата работи от партньора по тунела и се проваля отвсякъде другаде.

На входния сървър широко правило за masquerade е обичайният виновник. То пренаписва публичния източник към основния адрес на сървъра и клиентът никога не вижда истинския:

iptables -t nat -S POSTROUTING

Ограничете NAT до частните VPN клиенти, които се нуждаят от него, и оставете делегирания префикс непреведен. След това потвърдете, че сървърът изобщо препраща префикса, защото верига за препращане със забрана по подразбиране го изхвърля тихо.

Проверете двете посоки, преди да се доверите

Проверката е четири наблюдения, не едно. Потвърдете, че маршрутът на доставчика пристига, ядрото изпраща префикса в тунела, OpenVPN го приписва на правилния клиент и отговорът се връща с непокътнат публичен източник. Всяко наблюдение има своя команда, така че провалът сочи към слой, а не към целия дизайн. Изпълнявайте ги в този ред след всяка промяна на конфигурацията.

Питайте ядрото по кой път тръгва делегиран адрес и наблюдавайте тунела, докато тече заявка:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Филтрирането на обратния път може да обезсмисли правилен маршрут. Проверете ефективната настройка на тунела и на uplink и помнете, че строгият режим отхвърля трафик, чийто източник не съвпада с интерфейса, на който е пристигнал:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Накрая тествайте случая на отказ. Спрете тунела и потвърдете, че публичният префикс не изтича през обичайния uplink. Възстановяването на VPN трябва да върне услугата, без да разширява портовете, които хостът открива.