openfortivpn oerskriuwt hieltyd DNS? Fyn de echte eigner

Folgje de ferbining fan it momint dat dy omheech komt: de klient autentisearret, pppd ûnderhannelet, en dan skriuwt eat DNS-ynstellings yn it bestjoeringssysteem. As jo allinnich witte dat de VPN jo resolver feroare hat, witte jo noch net hokker fan dy stadia it dien hat. Twa fan harren kinne, en op in klient dy't de dokumintearre pppd-yntegraasje brûkt rinne se ticht genôch byinoar om as ien akteur te lykjen. It neamen fan de skriuwer is de earste stap; it kiezen fan syn ferfanging is de twadde, en dat is in aparte beslissing mei syn eigen falmodi.

De folchoarder hjirûnder folget de klient nei bûten: wat de ferbining feroare hat, hokker skeakel hokker skriuwer ûnderdrukt, wa't oernimme moat en hoe't jo befestigje dat it resultaat in werferbining oerlibbet. Elk stadium lit in oar spoar nei, en it spoar is wat jo fertelt oft de oerdracht echt bard is.

Begjin mei wat de ferbining echt feroare hat

Ferbyn jo ien kear mei jo gewoane oanrop en ferlykje de oplossing foar en nei. Op in Linux-host mei systemd-resolved printsje resolvectl status de DNS-tsjinners en sykdominen per keppeling, en in nije tun- of ppp-keppeling mei syn eigen tsjinners is de fingerôfdruk fan in fernijing oan 'e kliïntkant. Op macOS lit scutil --dns de resolverkonfiguraasje sjen yn 'e folchoarder wêryn applikaasjes dy rieplachtsje.

Ferlykje dat mei it bestân dat jo ferwachte dat feroarje soe. In ferbiningbûn yngong yn 'e werjeftte per keppeling en in oerskreaune /etc/resolv.conf binne twa ferskillende útkomsten, en de twadde kin in symboalyske keppeling wêze dy't hielendal troch eat oars beheard wurdt. Skriuw it resolveradres, de sykdominen en de ynterfacenamme op itselde momint op; in feroaring yn ien fan harren wiist op in oare skriuwer. Sûnder dy basisline is elke lettere ferbettering in gissing oer hokker fan trije komponinten beweecht is.

De twa skeakels en de skriuwer dy't elk stil makket

openfortivpn dokumintearret in opsjefragmint dat beide skriuwers útskeakelet dy't it kontrolearje kin, en elke skeakel hat in folslein útskreaun ekwivalint dat de hânlieding as deselde ynstelling behannelet.

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 keart dat de klient de DNS-tsjinners tapast dy't er fan 'e poarte leard hat, wylst --pppd-no-peerdns keart dat pppd peer-DNS yn it systeem triuwt. De hânlieding fan upstream warskôget dat DNS-fernijingen fia PPP wediuverje kinne mei de eigen DNS-fernijingen fan 'e klient, en dêrom hearre beide skeakels yn it fragmint, ynstee dat ien fan beiden as genôch beskôge wurdt.

Gjin fan de skeakels neamt in ferfangende resolver, en gjinien keart in netwurkbehearder, in DHCP-klient of in aparte VPN-yntegraasje derfan dat er dêrnei oplossing skriuwt. Twa skriuwers stil meitsje lit it fjild iepen ynstee fan besit. As in tredde komponint al DNS beheart, feroaret it fragmint neat dat jo waarnimme kinne; as neat it beheart, hawwe jo krekt de iennige boarne fan partikuliere namme-oplossing fuorthelle. Dat is allinnich in jildige regeling as de ferfangende eigner earst keazen en op himsels test is.

Kies de eigner foardat jo eat útskeakele

Beslis earst wa't de fragen foar wurknammen beantwurdet, want dy kar beheint alles dêrnei. It behâlden fan 'e besteande resolver betsjut dat de partikuliere sône al berikber wêze moat fan wêr't de klient ek sit, en in partikuliere resolver yn it kantoar hat in rûte nedich dy't it omheech kommen fan 'e tunnel oerlibbet. It stjoeren fan elke fraach nei ien ynterne tsjinst is in tredde belied mei in skerper falmodus: as dy tsjinst net berikber is, falle iepenbiere nammen tegearre mei de partikuliere.

Rûte-eignerskip bliuwt mei opsetsin apart. De rûte-opsjes binne net ferplicht om't jo DNS feroare hawwe, en it útskeakeljen fan rûte-ynstallaasje sûnder in ferfanging te ynstallearjen kin de resolver dy't jo krekt keazen hawwe ûnberikber meitsje. Kontrolearje de rûtetabel spesifyk foar it resolveradres, net allinnich foar it applikaasjesubnet dat jo tafallich test hawwe.

Kontrolearje de oplossing per keppeling, net per bestân

In inkelse /etc/resolv.conf is gjin ynventaris fan wat applikaasjes echt brûke op in host mei beheinde of per-domein-oplossing, dus lês de resolversteat sa't it platfoarm dy bleatleit.

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

Freegje ien partikuliere namme en ien iepenbiere namme as de ferbining omheech is, en notearje hokker keppeling op elk antwurde. Wêr't de VPN-keppeling in syklist per domein hat, kin in partikuliere namme korrekt oplosse wylst in iepenbiere namme noch nei de lokale resolver giet, en dy splitsing is it ûntwerp dat wurket, net in mankemint. As de partikuliere fraach mislearret, ûndersykje de rûte nei de resolver foardat jo DNS wer oanreitsje; as er slagget wylst in applikaasje noch mislearret, lêst de applikaasje miskien in eigen cachet of apart konfigurearre resolver.

Ferbyn jo opnij en befestigje de ûntkoppele steat

Bring de ferbining del en werhelje beide fragen. Wat de keazen eigner ynstallearre hat, moat troch dy eigner fuorthelle of werombrocht wurde, net efterlitten troch de klient dy't jo stil makke hawwe. In ferâldere yngong per keppeling dy't de tunnel oerlibbet, bliuwt partikuliere fragen stjoeren nei in adres dat net mear berikber is.

Ferbyn jo dan opnij en lês deselde trije wearden wer: resolveradres, sykdominen, ynterface.

As se oerienkomme mei it belied dat jo opskreaun hawwe, is de oerdracht foltôge en is de VPN-klient net langer ien fan 'e skriuwers. As in wearde in pear sekonden nei it omheech kommen fan 'e keppeling werom driuwt, past eat oars noch konfiguraasje ta, en de folgjende stap is dat komponint te identifisearjen ynstee fan noch in flagge ta te foegjen. De einsteat dy't jo wolle is sûnder foarfallen: ien eigner, ien dokumintearre belied en in ûntkoppele host dy't krekt sa oplost as foardat de tunnel bestie.