Старият ви маршрут по подразбиране умишлено остава след OpenVPN

Свързвате тунела, изпълнявате ip route и първоначалният шлюз по подразбиране все още е там. Първата мисъл е, че клиентът не е поел маршрута, затова изтривате маршрута по подразбиране ръчно и губите връзката напълно. Този запис трябва да остане. С redirect-gateway def1 OpenVPN инсталира два по-конкретни маршрута, които стоят над обикновения маршрут по подразбиране, вместо да го заменят. Старият шлюз остава и спира да носи трафика, който сте тествали.

Какво всъщност прави def1

Флагът добавя 0.0.0.0/1 и 128.0.0.0/1, насочени към тунела. 0.0.0.0/1 покрива всеки адрес, чийто първи октет е от 0 до 127, а 128.0.0.0/1 — от 128 до 255, така че всяка дестинация IPv4 има съвпадение, по-конкретно от стария маршрут по подразбиране. Дължината на префикса, а не метриката, решава кой маршрут печели.

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

Защо /1, а не /0

Маршрутизацията избира най-дългия съвпадащ префикс, а не най-ниската метрика, затова /1 побеждава /0 каквото и да казва метриката на маршрута по подразбиране. Двете половини съществуват, защото един /1 покрива само половината от пространството; при наличие само на 0.0.0.0/1 всичко от 128.0.0.0 нагоре продължава да следва стария маршрут по подразбиране, което дава объркващия симптом — някои сайтове работят, други не.

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

Прочетете реална маршрутна таблица

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

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

Проверете кой маршрут наистина поема пакетът

По-конкретни маршрути все още могат да победят: маршрут за частен диапазон, локална подмрежа или собствения адрес на VPN сървъра е по-дълъг от /1. Тунелът се нуждае от външен път до своя сървър и изпращането на тази връзка обратно в тунела веднага ще го счупи. В Linux питайте ядрото, вместо да четете таблицата на око: ip route get с дестинацията, която ви интересува, отпечатва избрания маршрут, интерфейса и източника. Ако е настроена маршрутизация по политики, прегледайте и правилата, защото правило може да избере друга таблица, преди да се погледне основната.

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

Какво не покрива def1

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

Аварийният прекъсвач отговаря на друг въпрос: какво прави машината, когато тунелът падне. Приоритетът на маршрутите решава накъде отива трафикът, докато тунелът е активен; той не решава какво прави после защитната стена. Ред на работа: прочетете таблицата, потвърдете, че и двете половини съществуват, изпълнете ip route get за проблемната дестинация, проверете правилата на политиките и след това погледнете IPv6 отделно. Оставете стария маршрут по подразбиране там, където е.