openfortivpn nuolat perrašo DNS? Raskite tikrąjį savininką

Sekite ryšį nuo tos akimirkos, kai jis pakyla: klientas autentifikuojasi, pppd derasi, o paskui kažkas įrašo DNS nustatymus į operacinę sistemą. Jei žinote tik tai, kad VPN pakeitė jūsų resolverį, dar nežinote, kuris iš tų etapų tai padarė. Du iš jų gali, o kliente, naudojančiame dokumentuotą pppd integraciją, jie veikia pakankamai arti vienas kito, kad atrodytų kaip vienas veikėjas. Rašytojo įvardijimas yra pirmas žingsnis; jo pakaitalo pasirinkimas yra antras, ir tai atskiras sprendimas su savais gedimo būdais.

Žemiau pateikta seka seka klientą į išorę: ką pakeitė ryšys, kuris jungiklis nutildo kurį rašytoją, kas turėtų perimti ir kaip patvirtinti, kad rezultatas išgyvena pakartotinį prisijungimą. Kiekvienas etapas palieka skirtingą pėdsaką, ir būtent pėdsakas pasako, ar perdavimas tikrai įvyko.

Pradėkite nuo to, ką ryšys iš tikrųjų pakeitė

Prisijunkite vieną kartą įprasta komanda ir palyginkite sprendimą prieš ir po. Linux pagrindiniame kompiuteryje su systemd-resolved resolvectl status išspausdina DNS serverius ir paieškos domenus kiekvienai jungčiai, o nauja tun arba ppp jungtis su savo serveriais yra kliento pusės atnaujinimo piršto atspaudas. macOS scutil --dns rodo resolverio konfigūraciją ta tvarka, kuria programos ją konsultuoja.

Palyginkite tai su failu, kurį tikėjotės pakeisti. Jungčiai priskirtas įrašas rodinyje pagal jungtis ir perrašytas /etc/resolv.conf yra du skirtingi rezultatai, o antrasis gali būti simbolinė nuoroda, kurią visiškai valdo kažkas kita. Užsirašykite resolverio adresą, paieškos domenus ir sąsajos pavadinimą tuo pačiu metu; bet kurio iš jų pokytis rodo į kitą rašytoją. Be šios bazinės linijos kiekvienas vėlesnis pataisymas yra spėjimas, kuri iš trijų dalių pajudėjo.

Du jungikliai ir rašytojas, kurį kiekvienas nutildo

openfortivpn dokumentuoja parinkčių fragmentą, kuris išjungia abu rašytojus, kuriuos jis gali valdyti, ir kiekvienas jungiklis turi iki galo išrašytą atitikmenį, kurį vadovas laiko ta pačia nuostata.

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 neleidžia klientui taikyti DNS serverių, kuriuos jis sužinojo iš tinklo vartų, o --pppd-no-peerdns neleidžia pppd įstumti partnerio DNS į sistemą. upstream vadovas įspėja, kad DNS atnaujinimai per PPP gali lenktyniauti su paties kliento DNS atnaujinimais, todėl abu jungikliai priklauso fragmentui, o ne vienas iš jų laikomas pakankamu.

Nė vienas jungiklis neįvardija pakaitinio resolverio, ir nė vienas netrukdo tinklo tvarkyklei, DHCP klientui ar atskirai VPN integracijai vėliau įrašyti sprendimą. Dviejų rašytojų nutildymas palieka lauką atvirą, o ne valdomą. Jei trečia dalis jau valdo DNS, fragmentas nekeičia nieko, ką galite pastebėti; jei niekas jo nevaldo, ką tik pašalinote vienintelį privatų vardų sprendimo šaltinį. Tai galiojanti tvarka tik tada, kai pakaitinis savininkas pirmiausia buvo pasirinktas ir išbandytas atskirai.

Pasirinkite savininką prieš ką nors išjungdami

Pirmiausia nuspręskite, kas atsakys į užklausas dėl darbo vardų, nes šis pasirinkimas apriboja viską, kas bus toliau. Išlaikyti esamą resolverį reiškia, kad privati zona jau turi būti pasiekiama iš ten, kur klientas yra, o privatus resolveris biure turi turėti maršrutą, kuris išgyvena tunelio pakilimą. Siųsti kiekvieną užklausą vienai vidinei paslaugai yra trečioji politika su aštresniu gedimo būdu: kai ta paslauga nepasiekiama, vieši vardai nepavyksta kartu su privačiais.

Maršruto nuosavybė sąmoningai lieka atskira. Maršruto parinktys nėra būtinos todėl, kad pakeitėte DNS, o maršruto diegimo išjungimas neįdiegus pakaitalo gali padaryti ką tik pasirinktą resolverį nepasiekiamą. Patikrinkite maršrutų lentelę konkrečiai resolverio adresui, o ne tik tos programos potinkliui, kurią atsitiktinai testavote.

Tikrinkite sprendimą kiekvienai jungčiai, o ne failui

Vienas /etc/resolv.conf nėra sąrašas to, ką programos iš tikrųjų naudoja pagrindiniame kompiuteryje su apribotu arba pagal domeną sprendimu, todėl skaitykite resolverio būseną taip, kaip ją atskleidžia platforma.

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

Užklauskite vieną privatų vardą ir vieną viešą vardą, kai ryšys pakilęs, ir pažymėkite, kuri jungtis atsakė į kiekvieną. Ten, kur VPN jungtis turi paieškos sąrašą pagal domenus, privatus vardas gali būti išspręstas teisingai, o viešas vardas vis dar eina į vietinį resolverį, ir šis atskyrimas yra veikiantis dizainas, o ne gedimas. Jei privati užklausa nepavyksta, prieš vėl liesdami DNS patikrinkite maršrutą į resolverį; jei ji pavyksta, o programa vis dar nepavyksta, programa galbūt skaito savo podėlyje laikomą ar atskirai sukonfigūruotą resolverį.

Prisijunkite iš naujo ir patvirtinkite atjungtą būseną

Nuleiskite ryšį ir pakartokite abi užklausas. Ką pasirinktas savininkas įdiegė, tas savininkas turi pašalinti arba atkurti, o ne palikti jūsų nutildytas klientas. Pasenęs įrašas pagal jungtį, kuris išgyvena tunelį, toliau siunčia privačias užklausas į adresą, kuris nebepasiekiamas.

Tada prisijunkite iš naujo ir perskaitykite tas pačias tris reikšmes: resolverio adresą, paieškos domenus, sąsają.

Jei jos atitinka politiką, kurią užsirašėte, perdavimas baigtas ir VPN klientas nebėra vienas iš rašytojų. Jei reikšmė po kelių sekundžių nuo jungties pakilimo grįžta atgal, kažkas kita vis dar taiko konfigūraciją, ir kitas žingsnis yra nustatyti tą dalį, o ne pridėti dar vieną vėliavėlę. Norima galutinė būsena yra be įvykių: vienas savininkas, viena dokumentuota politika ir atjungtas pagrindinis kompiuteris, kuris sprendžia lygiai taip, kaip prieš atsirandant tuneliui.