VPN клиент изтрива добавения от вас маршрут? Използвайте таблица с правила

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

Една /24 за лабораторен принтер изчезва между две извиквания на ip route show, а журналът на клиента казва само, че мрежата се е променила. Нямаше нищо нередно в командата, префикса или правата ви. Корпоративен клиент, който притежава маршрутния модел на хоста, налага отново този модел, когато някой друг го редактира, затова добавеният от вас запис се премахва като натрапник. Борбата с него в същата таблица е губеща позиция. Решението е напълно да спрете да се състезавате за тази таблица и да поставите изключението там, където мониторът никога не гледа.

Мониторът обяснява липсващия маршрут

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

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

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

Втората таблица е невидима за монитора

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

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

Изградете изключението, после го накарайте да печели

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

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get разрешава маршрута, който ядрото ще използва, включително устройството и адреса на източника. Не отпечатва идентификатора на таблицата, затова го съчетайте с ip rule show, когато трябва да потвърдите коя таблица е спечелила. Заедно те отговарят на единствения важен въпрос: напуска ли трафикът към този адрес там, където сте искали?

Други форми на същата идея

Моделът се обобщава, щом спрете да мислите с дестинации. Локална подмрежа може да остане достъпна, докато тунелът държи маршрута по подразбиране. Отговорите от SSH сървър, свързан към LAN, могат да излизат през интерфейса, по който са пристигнали, вместо да изчезват в тунела. А правило, базирано на интерфейс, може да изтласка всичко, пристигащо на безжичен интерфейс, в тунела, докато трафикът, който хостът сам генерира, остава на Ethernet:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Последният случай съвпада с входящия интерфейс, а не с дестинацията, което е различен тип правило и различен начин на мислене. Пренасочваният трафик също изисква включен net.ipv4.ip_forward, а далечната страна трябва да маршрутизира диапазона на източника обратно или да го транслира; правило на една машина никога не създава другата половина от пътя.

Отнасяйте се към правилото като към временно

Правилата и маршрутите в таблици живеят в паметта. След повторно свързване устройството на тунела може да бъде преименувано, зададеният адрес може да се премести, а правило със старата стойност тихо спира да съвпада. Приложете отново цялата промяна от един скрипт, който я притежава, после проверете отново ip rule show, текущото име на устройството и нов ip route get срещу реална дестинация, преди да се доверите на изключението.

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

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

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