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 больш не адзін з пісьменнікаў. Калі значэнне адкочваецца назад праз некалькі секунд пасля ўзняцця сувязі, нешта іншае ўсё яшчэ ўжывае канфігурацыю, і наступны крок — вызначыць гэты кампанент, а не дадаць яшчэ адзін сцяг. Канечны стан, які вы хочаце, — незаўважны: адзін уладальнік, адна дакументаваная палітыка і адключаны хост, які развязвае менавіта так, як рабіў гэта да з'яўлення тунэля.