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-клиентот повеќе не е еден од пишувачите. Ако вредност се врати назад неколку секунди по кревањето на врската, нешто друго сѐ уште применува конфигурација, и следниот чекор е да го идентификувате тој дел, а не да додадете уште едно знаменце. Крајната состојба што ја сакате е без настани: еден сопственик, една документирана политика и исклучен домаќин што решава точно како пред да постои тунелот.