openfortivpn vazhdon të mbishkruajë DNS-në? Gjeni pronarin e vërtetë

Ndiqni lidhjen që nga momenti kur ngrihet: klienti vërtetohet, pppd negocion, dhe pastaj diçka shkruan cilësimet e DNS-së në sistemin operativ. Nëse dini vetëm se VPN-ja ndryshoi zgjidhësin tuaj, nuk e dini ende se cila nga ato faza e bëri atë. Dy prej tyre mundet, dhe në një klient që përdor integrimin e dokumentuar të pppd ato punojnë mjaft afër njëra-tjetrës për të dukur si një aktor i vetëm. Emërtimi i shkruesit është hapi i parë; zgjedhja e zëvendësit të tij është i dyti, dhe ky është një vendim i veçantë me mënyrat e veta të dështimit.

Sekuenca më poshtë ndjek klientin nga jashtë: çfarë ndryshoi lidhja, cili çelës hesht cilin shkrues, kush duhet të marrë përsipër dhe si të konfirmoni që rezultati i mbijeton një rilidhjeje. Çdo fazë lë një gjurmë të ndryshme, dhe gjurma është ajo që ju tregon nëse dorëzimi ndodhi vërtet.

Filloni me atë që lidhja ndryshoi vërtet

Lidhuni një herë me komandën tuaj të zakonshme dhe krahasoni zgjidhjen para dhe pas. Në një host Linux që ekzekuton systemd-resolved, resolvectl status shtyp serverët DNS dhe domenet e kërkimit për çdo lidhje, dhe një lidhje e re tun ose ppp që mban serverët e vet është gjurma e gishtit të një përditësimi nga ana e klientit. Në macOS, scutil --dns tregon konfigurimin e zgjidhësit në rendin që aplikacionet e konsultojnë.

Krahasojeni këtë me skedarin që prisnit të ndryshonte. Një zë i lidhur me lidhjen në pamjen për çdo lidhje dhe një /etc/resolv.conf i rishkruar janë dy rezultate të ndryshme, dhe i dyti mund të jetë një lidhje simbolike që menaxhohet plotësisht nga diçka tjetër. Shënoni adresën e zgjidhësit, domenet e kërkimit dhe emrin e ndërfaqes në të njëjtin moment; një ndryshim në cilindo prej tyre tregon një shkrues tjetër. Pa atë vijë bazë, çdo korrigjim i mëvonshëm është një hamendje se cili nga tre komponentët lëvizi.

Dy çelësat dhe shkruesi që secili hesht

openfortivpn dokumenton një fragment opsionesh që fik të dy shkruesit që mund të kontrollojë, dhe çdo çelës ka një ekuivalent të shkruar plotësisht që manuali e trajton si të njëjtin cilësim.

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 e pengon klientin të zbatojë serverët DNS që mësoi nga porta, ndërsa --pppd-no-peerdns e pengon pppd të shtyjë DNS-në e palës në sistem. Manuali i upstream paralajmëron se përditësimet e DNS-së përmes PPP mund të garojnë me përditësimet e vetë klientit, prandaj të dy çelësat i përkasin fragmentit në vend që ndonjëri prej tyre të konsiderohet i mjaftueshëm.

Asnjë çelës nuk emërton një zgjidhës zëvendësues, dhe asnjëri nuk pengon një menaxher rrjeti, një klient DHCP ose një integrim të veçantë VPN të shkruajë zgjidhjen më pas. Heshtja e dy shkruesve e lë fushën të hapur dhe jo të zotëruar. Nëse një komponent i tretë tashmë menaxhon DNS-në, fragmenti nuk ndryshon asgjë që mund të vëzhgoni; nëse asgjë nuk e menaxhon atë, sapo hoqët burimin e vetëm të zgjidhjes së emrave privatë. Ky është një rregullim i vlefshëm vetëm kur pronari zëvendësues u zgjodh fillimisht dhe u testua veçmas.

Zgjidhni pronarin përpara se të çaktivizoni çdo gjë

Vendosni fillimisht kush u përgjigjet pyetjeve për emrat e punës, sepse ai zgjedhje kushtëzon gjithçka që vjen pas. Mbajtja e zgjidhësit ekzistues do të thotë që zona private duhet të jetë tashmë e arritshme nga kudo që ndodhet klienti, dhe një zgjidhës privat brenda zyrës ka nevojë për një rrugë që i mbijeton ngritjes së tunelit. Dërgimi i çdo pyetjeje në një shërbim të vetëm të brendshëm është një politikë e tretë me një mënyrë dështimi më të mprehtë: kur ai shërbim nuk është i arritshëm, emrat publikë dështojnë bashkë me ata privatë.

Pronësia e rrugës mbetet e ndarë me qëllim. Opsionet e rrugës nuk kërkohen sepse ndryshuat DNS-në, dhe çaktivizimi i instalimit të rrugës pa instaluar një zëvendës mund ta bëjë zgjidhësin që sapo zgjodhët të paarritshëm. Kontrolloni tabelën e rrugëtimit posaçërisht për adresën e zgjidhësit, jo vetëm për nënrrjetin e aplikacionit që testuat rastësisht.

Kontrolloni zgjidhjen për çdo lidhje, jo për çdo skedar

Një /etc/resolv.conf i vetëm nuk është inventar i asaj që aplikacionet përdorin vërtet në një host me zgjidhje të kufizuar ose sipas domenit, prandaj lexoni gjendjen e zgjidhësit ashtu siç e ekspozon platforma.

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

Pyetni një emër privat dhe një emër publik pasi lidhja të ngrihet, dhe shënoni cila lidhje u përgjigj për secilin. Aty ku lidhja VPN mban një listë kërkimi sipas domenit, një emër privat mund të zgjidhet saktë ndërsa një emër publik shkon ende te zgjidhësi lokal, dhe kjo ndarje është dizajni që funksionon dhe jo një defekt. Nëse pyetja private dështon, inspektoni rrugën drejt zgjidhësit përpara se të prekni përsëri DNS-në; nëse ajo ka sukses ndërsa një aplikacion ende dështon, aplikacioni mund të lexojë një zgjidhës të vetin të ruajtur në cache ose të konfiguruar veçmas.

Rilidhuni dhe konfirmoni gjendjen e shkëputur

Ulni lidhjen dhe përsëritni të dyja pyetjet. Çfarëdo që instaloi pronari i zgjedhur duhet ta heqë ose ta rikthejë ai pronar, jo ta lërë pas klienti që heshtët. Një zë i vjetruar për çdo lidhje që i mbijeton tunelit vazhdon të dërgojë pyetje private në një adresë që nuk është më e arritshme.

Pastaj rilidhuni dhe lexoni përsëri të njëjtat tre vlera: adresa e zgjidhësit, domenet e kërkimit, ndërfaqja.

Nëse ato përputhen me politikën që shënuat, dorëzimi është i plotë dhe klienti VPN nuk është më një nga shkruesit. Nëse një vlerë kthehet mbrapsht disa sekonda pasi lidhja ngrihet, diçka tjetër po zbaton ende konfigurimin, dhe hapi tjetër është të identifikoni atë komponent në vend që të shtoni një flamur tjetër. Gjendja përfundimtare që dëshironi është pa ngjarje: një pronar, një politikë e dokumentuar dhe një host i shkëputur që zgjidh saktësisht si përpara se tuneli të ekzistonte.