openfortivpn постоянно презаписва DNS? Открийте истинския собственик

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

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

Започнете с това какво всъщност промени връзката

Свържете се веднъж с обичайната си команда и сравнете разрешаването преди и след. На Linux хост със systemd-resolved resolvectl status показва DNS сървърите и домейните за търсене за всяка връзка, а нова връзка tun или ppp със свои собствени сървъри е отпечатъкът на актуализация от страна на клиента. На macOS scutil --dns показва конфигурацията на резолвера в реда, в който приложенията я консултират.

Сравнете това с файла, който сте очаквали да се промени. Запис, обвързан с връзка, в изгледа за всяка връзка и презаписан /etc/resolv.conf са два различни изхода и вторият може да е символична връзка, управлявана изцяло от нещо друго. Запишете адреса на резолвера, домейните за търсене и името на интерфейса в един и същ момент; промяна в който и да е от тях сочи към различен писач. Без тази базова линия всяка следваща поправка е догадка кой от три компонента се е преместил.

Двата превключвателя и писачът, който всеки заглушава

openfortivpn документира фрагмент с опции, който изключва и двата писача, които може да контролира, а всеки превключвател има изписан докрай еквивалент, който ръководството третира като същата настройка.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns спира клиента да прилага DNS сървърите, които е научил от шлюза, а --pppd-no-peerdns спира pppd да вкарва DNS на партньора в системата. Ръководството на upstream предупреждава, че актуализациите на DNS по PPP могат да се състезават със собствените актуализации на DNS на клиента, поради което и двата превключвателя трябва да са във фрагмента, вместо някой от тях да се смята за достатъчен.

Нито един превключвател не посочва резервен резолвер и нито един не спира мрежов мениджър, DHCP клиент или отделна VPN интеграция да записва разрешаване след това. Заглушаването на два писача оставя полето отворено, а не притежавано. Ако трети компонент вече управлява DNS, фрагментът не променя нищо, което можете да наблюдавате; ако нищо не го управлява, току-що премахнахте единствения източник на разрешаване на частни имена. Това е валидна подредба само когато резервният собственик е избран първо и тестван самостоятелно.

Изберете собственика, преди да изключите нещо

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

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

Проверявайте разрешаването за всяка връзка, не за файл

Един /etc/resolv.conf не е опис на това, което приложенията всъщност използват на хост с обхватно или по домейн разрешаване, затова четете състоянието на резолвера така, както платформата го показва.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

Свържете се отново и потвърдете изключеното състояние

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

След това се свържете отново и прочетете същите три стойности: адрес на резолвера, домейни за търсене, интерфейс.

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