Защо маршрут през пълен тунел отрязва сървъра, който го пренася

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

Маршрут, който изяжда собствения си транспорт

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

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

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

Инсталирайте изключението преди маршрута по подразбиране

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

Повечето клиенти правят това без подкана. OpenVPN търси отдалечения адрес и го закрепва, преди да пренапише шлюза по подразбиране, а неговата опция route-delay съществува за платформи, където тази последователност се състезава. wg-quick поема съвсем различен път, маркирайки пакети и консултирайки се с правило за политика вместо да добавя изключение. Различни механизми, едно изискване: външният пакет трябва да избяга от тунела, който създава.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

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

Огледалният образ на сървъра

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

Изключения, които тунелът продължава да краде

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

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

Изключение, което никой не е записал, е изключение, което следващото преустройство ще изпусне тихо.

Докажете го след повторно свързване, не преди

Тествайте три дестинации, не една: крайната точка, частен адрес зад тунела и публичен адрес отвъд него. Едно успешно търсене не казва почти нищо за другите две.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

След това рестартирайте връзката, защото клиент, който преустройва таблицата си при повторно свързване, ще изхвърли маршрут, който сте въвели на ръка. Ако има kill switch, проверете дали крайната точка е разрешена, иначе тунелът не може да се върне след промяна в мрежата и симптомът изглежда като прекъсване. Съхранявайте изключението в профила или unit файла, а не в историята на shell, така че повторното свързване да го пресъздаде, вместо да го изтрие.