Пълен тунел или маршрут до крайната точка: как да запазим VPN сървъра достъпен

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

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

Вътрешният и външният трафик са различни решения

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

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

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

Вариант първи: маршрут до хост за крайната точка

Директният подход добавя маршрут за адреса на сървъра през първоначалния шлюз. Отнема един ред. Той е видим за всеки, който чете таблицата. Освен това лесно се обяснява в запис за промяна.

Слабостта му се проявява, когато основният път се промени. Запазеният маршрут посочва шлюз и интерфейс от старата мрежа. След смяна на Wi-Fi този шлюз може да не съществува, а маршрутът остава, изглежда правилен и не прави нищо.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Името на хоста прави това по-трудно. Ако крайната точка е име, което се разрешава до няколко адреса, изключението трябва да покрива действително използвания адрес. По-късна заявка може да върне нещо, което маршрутът никога не е покривал.

Вариант втори: защита на сокета

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

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

Цената е видимостта. Нищо в таблицата за маршрутизация не показва изключението, затова рецензент, който търси маршрут до хост, не намира нищо и може да заключи, че дизайнът е опасен. Защитата живее в кода на клиента и в правилата за политика, които този код инсталира.

Как да избираме между тях

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

Нито един от механизмите не премахва нуждата адресът на сървъра да е достъпен изобщо. Частният шлюз има публичен адрес за слушане и точно този адрес трябва да остане извън тунела. Вътрешните мрежи зад него стават достъпни само след като тунелът съществува.

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