openfortivpn nemitīgi pārraksta DNS? Atrodiet īsto īpašnieku

Izsekojiet savienojumam no brīža, kad tas paceļas: klients autentificējas, pppd pārrunā, un tad kaut kas ieraksta DNS iestatījumus operētājsistēmā. Ja jūs zināt tikai to, ka VPN nomainīja jūsu atrisinātāju, jūs vēl nezināt, kurš no šiem posmiem to izdarīja. Divi no tiem var, un klientā, kas izmanto dokumentēto pppd integrāciju, tie darbojas pietiekami tuvu viens otram, lai izskatītos kā viens dalībnieks. Rakstītāja nosaukšana ir pirmais solis; tā aizstājēja izvēle ir otrais, un tas ir atsevišķs lēmums ar saviem atteices režīmiem.

Zemāk esošā secība seko klientam uz āru: ko mainīja savienojums, kurš slēdzis apklusina kuru rakstītāju, kam būtu jāpārņem un kā apstiprināt, ka rezultāts pārdzīvo atkārtotu savienojumu. Katrs posms atstāj citu pēdu, un tieši pēda pasaka, vai nodošana patiešām notika.

Sāciet ar to, ko savienojums patiešām mainīja

Pieslēdzieties vienreiz ar savu ierasto komandu un salīdziniet atrisinājumu pirms un pēc. Linux resursdatorā ar systemd-resolved resolvectl status izdrukā DNS serverus un meklēšanas domēnus katram savienojumam, un jauns tun vai ppp savienojums ar saviem serveriem ir klienta puses atjauninājuma pirkstu nospiedums. macOS scutil --dns parāda atrisinātāja konfigurāciju tādā secībā, kādā lietojumprogrammas to konsultē.

Salīdziniet to ar failu, kuru gaidījāt izmainītu. Savienojumam piesaistīts ieraksts skatā pa savienojumiem un pārrakstīts /etc/resolv.conf ir divi dažādi iznākumi, un otrais var būt simboliska saite, ko pilnībā pārvalda kaut kas cits. Pierakstiet atrisinātāja adresi, meklēšanas domēnus un saskarnes nosaukumu tajā pašā mirklī; izmaiņas jebkurā no tiem norāda uz citu rakstītāju. Bez šīs bāzes līnijas katrs vēlākais labojums ir minējums par to, kura no trim daļām ir pakustējusies.

Divi slēdži un rakstītājs, ko katrs no tiem apklusina

openfortivpn dokumentē opciju fragmentu, kas izslēdz abus rakstītājus, kurus tas var kontrolēt, un katram slēdzim ir pilnībā izrakstīts ekvivalents, ko rokasgrāmata uzskata par to pašu iestatījumu.

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 neļauj klientam piemērot DNS serverus, ko tas uzzināja no vārtejas, bet --pppd-no-peerdns neļauj pppd iespiest partnera DNS sistēmā. upstream rokasgrāmata brīdina, ka DNS atjauninājumi caur PPP var sacensties ar paša klienta DNS atjauninājumiem, tāpēc abi slēdži pieder fragmentam, nevis kāds no tiem tiek uzskatīts par pietiekamu.

Neviens slēdzis nenosauc aizvietotāju atrisinātāju, un neviens netraucē tīkla pārvaldniekam, DHCP klientam vai atsevišķai VPN integrācijai vēlāk rakstīt atrisinājumu. Divu rakstītāju apklusināšana atstāj lauku atvērtu, nevis piederīgu. Ja trešā daļa jau pārvalda DNS, fragments nemaina neko, ko jūs varat novērot; ja nekas to nepārvalda, jūs tikko noņēmāt vienīgo privāto vārdu atrisināšanas avotu. Tas ir derīgs izkārtojums tikai tad, ja aizvietotājs īpašnieks vispirms tika izvēlēts un pārbaudīts atsevišķi.

Izvēlieties īpašnieku, pirms kaut ko atslēdzat

Vispirms izlemiet, kas atbild uz darba nosaukumu vaicājumiem, jo šī izvēle ierobežo visu, kas seko. Esošā atrisinātāja saglabāšana nozīmē, ka privātajai zonai jau jābūt sasniedzamai no vietas, kur klients atrodas, un privātam atrisinātājam birojā vajadzīgs maršruts, kas pārdzīvo tuneļa pacelšanos. Katra vaicājuma sūtīšana vienam iekšējam servisam ir trešā politika ar asāku atteices režīmu: kad šis serviss nav sasniedzams, publiskie nosaukumi cieš neveiksmi kopā ar privātajiem.

Maršruta īpašumtiesības apzināti paliek atsevišķas. Maršruta opcijas nav vajadzīgas tāpēc, ka jūs mainījāt DNS, un maršruta instalēšanas izslēgšana, neinstalējot aizstājēju, var padarīt tikko izvēlēto atrisinātāju nesasniedzamu. Pārbaudiet maršrutēšanas tabulu konkrēti atrisinātāja adresei, ne tikai tās lietojumprogrammas apakštīklam, kuru nejauši testējāt.

Pārbaudiet atrisinājumu katram savienojumam, nevis failam

Viens /etc/resolv.conf nav saraksts ar to, ko lietojumprogrammas patiešām izmanto resursdatorā ar ierobežotu vai domēnu atrisinājumu, tāpēc lasiet atrisinātāja stāvokli tā, kā to atklāj platforma.

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

Vaicājiet vienu privātu nosaukumu un vienu publisku nosaukumu, kad savienojums ir pacelts, un atzīmējiet, kurš savienojums atbildēja uz katru. Vietās, kur VPN savienojums nes domēnu meklēšanas sarakstu, privāts nosaukums var atrisināties pareizi, kamēr publisks nosaukums joprojām iet uz vietējo atrisinātāju, un šī sadalīšana ir strādājošs dizains, nevis bojājums. Ja privātais vaicājums neizdodas, pirms vēlreiz aiztikt DNS pārbaudiet maršrutu uz atrisinātāju; ja tas izdodas, kamēr lietojumprogramma joprojām neizdodas, lietojumprogramma, iespējams, lasa savu kešoto vai atsevišķi konfigurēto atrisinātāju.

Pieslēdzieties atkārtoti un apstipriniet atvienoto stāvokli

Nolaidiet savienojumu un atkārtojiet abus vaicājumus. Tas, ko izvēlētais īpašnieks instalēja, tam pašam īpašniekam ir jānoņem vai jāatjauno, nevis jāatstāj jūsu apklusinātajam klientam. Novecojis ieraksts pa savienojumiem, kas pārdzīvo tuneli, turpina sūtīt privātus vaicājumus uz adresi, kas vairs nav sasniedzama.

Pēc tam pieslēdzieties atkārtoti un nolasiet tos pašus trīs lielumus: atrisinātāja adresi, meklēšanas domēnus, saskarni.

Ja tie atbilst politikai, ko pierakstījāt, nodošana ir pabeigta un VPN klients vairs nav viens no rakstītājiem. Ja lielums pēc dažām sekundēm pēc savienojuma pacelšanās atgriežas atpakaļ, kaut kas cits joprojām piemēro konfigurāciju, un nākamais solis ir identificēt šo daļu, nevis pievienot vēl vienu karodziņu. Vēlamais gala stāvoklis ir bez notikumiem: viens īpašnieks, viena dokumentēta politika un atvienots resursdators, kas atrisina tieši tā, kā tas darīja pirms tuneļa pastāvēšanas.