Насочване на една LAN подмрежа през OpenVPN със запазен маршрут по подразбиране

Запазете маршрута по подразбиране за LAN, докато една подмрежа минава през тунела. Сравнете таблица с правила с редакции на главната таблица, после изберете NAT или маршрут от страна на сървъра.

Устройствата, които маршрутизират за LAN и едновременно се свързват към VPN, изпадат в същия спор със себе си: тунелът иска да притежава маршрута по подразбиране, а LAN има нужда да си го върне. Когато OpenVPN се свърже, той може да инсталира маршрут по подразбиране през тунела или двойка половин маршрути, което е правилно за лаптоп и грешно за шлюз, чиито съседи очакват отговори от LAN адреса му. Отговорът не е да пропуснете VPN. Отговорът е да дадете на двете решения различни таблици.

Един маршрут по подразбиране, двама собственици

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

OpenVPN има превключвател точно за това. route-noexec спира клиента да пипа главната таблица изобщо, а стойностите, които би използвал, се подават към скрипт route-up като route_vpn_gateway, dev и адресите на интерфейса. След това вие решавате коя таблица кой маршрут да получи, в код, който можете да прочетете по-късно.

Таблица с правила срещу пренаписване на главната

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

Отделната таблица е единственият вариант, който се мащабира отвъд една подмрежа. Дайте ѝ име веднъж, после се позовавайте на него по име, за да не се налага на никого да помни число:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Адресите тук са заместители. Заменете LAN префикса, шлюза на тунела и името на устройството от вашето собствено внедряване, преди да стартирате каквото и да е.

Правилото трябва да съвпада и с хоста

Правило, което съвпада само с LAN префикса, покрива пренасочените пакети. То не покрива трафика, който шлюзът сам създава, нито отговорите, които връща към LAN клиентите, а те носят LAN адреса на шлюза като свой източник. Тези търсения падат към main и все още могат да излязат през тунела.

Добавете второ правило за собствения LAN адрес на шлюза или разширете първото правило до набор, който включва и двете. Редът е важен: сложете по-конкретното правило първо и проверете резултата с търсене, което посочва източника изрично.

ip route get 203.0.113.9 from 192.168.50.1

Ако това показва устройството на тунела за дестинация, която трябва да остане локална, наборът от правила е грешен независимо какво съдържа таблицата.

NAT или маршрут от отсрещната страна

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

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Изберете NAT, когато не контролирате сървъра и не можете да добавите маршрути там. Изберете маршрута от страна на сървъра, когато журналите, контролът на достъпа или симетрията на обратния път са важни, защото маскирането изтрива оригиналния адрес от всичко, което отсрещната страна записва.

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

Направете така, че разделянето да преживее повторно свързване

Правилата и маршрутите, добавени на ръка, изчезват, когато интерфейсът бъде създаден наново, а остарял запис в таблицата може да надживее сесията, която го е оправдавала. Поставете правилото за таблицата, маршрута за тунела и записа за маскиране в скрипта route-up на клиента и изчистете таблицата в началото на скрипта, за да не може стар шлюз да оцелее в новата сесия.

Проверете от двата края: търсене на шлюза с LAN източник и истинска заявка от LAN клиент към дестинация, която трябва да мине през тунела. Маршрут, който съществува, но никога не се избира, се държи точно като липса на маршрут, докато не прочетете броячите.

Подобни статии