openfortivpn oorskryf steeds DNS? Vind die regte eienaar

Volg die verbinding van die oomblik dat dit opkom: die kliënt verifieer, pppd onderhandel, en dan skryf iets DNS-instellings in die bedryfstelsel. As jy net weet dat die VPN jou oplosser verander het, weet jy nog nie watter van daardie fases dit gedoen het nie. Twee van hulle kan, en op 'n kliënt wat die gedokumenteerde pppd-integrasie gebruik, hardloop hulle naby genoeg aan mekaar om soos 'n enkele rolspeler te lyk. Om die skrywer te benoem is die eerste stap; om die plaasvervanger te kies is die tweede, en dit is 'n aparte besluit met sy eie foutmodusse.

Die volgorde hieronder volg die kliënt na buite: wat die verbinding verander het, watter skakelaar watter skrywer onderdruk, wie veronderstel is om oor te neem, en hoe om te bevestig dat die resultaat 'n herverbinding oorleef. Elke fase laat 'n ander spoor, en dit is die spoor wat jou vertel of die oorhandiging werklik plaasgevind het.

Begin met wat die verbinding werklik verander het

Verbind een keer met jou gewone opdrag en vergelyk die oplossing voor en ná. Op 'n Linux-gasheer wat systemd-resolved gebruik, druk resolvectl status die DNS-bediener en soekdomeine per skakel, en 'n nuwe tun- of ppp-skakel met sy eie bedieners is die vingerafdruk van 'n kliëntkant-opdatering. Op macOS wys scutil --dns die oplosser-konfigurasie in die volgorde waarin toepassings dit raadpleeg.

Vergelyk dit met die lêer wat jy verwag het om te verander. 'n Verbinding-gebonde inskrywing in die per-skakel-aansig en 'n herskryfde /etc/resolv.conf is twee verskillende uitkomste, en die tweede kan 'n simskakel wees wat iets anders heeltemal bestuur. Teken die oplosser-adres, die soekdomeine en die koppelvlaknaam op dieselfde oomblik aan; 'n verandering in enige een van hulle dui op 'n ander skrywer. Sonder daardie basislyn is elke latere regstelling 'n raaiskoot oor watter van drie komponente beweeg het.

Die twee skakelaars en die skrywer wat elkeen stilmaak

openfortivpn dokumenteer 'n opsie-fragment wat albei skrywers wat dit kan beheer, afskakel, en elke skakelaar het 'n voluit geskrewe ekwivalent wat die handleiding as dieselfde instelling beskou.

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 keer dat die kliënt die DNS-bedieners toepas wat dit by die poort geleer het, terwyl --pppd-no-peerdns keer dat pppd eweknie-DNS in die stelsel instoot. Die opstroom-handleiding waarsku dat PPP-DNS-opdaterings met die kliënt se eie DNS-opdaterings kan resies jaag, en daarom hoort albei skakelaars in die fragment eerder as dat enige een as voldoende beskou word.

Nie een skakelaar noem 'n plaasvervanger-oplosser nie, en nie een keer dat 'n netwerkbestuurder, 'n DHCP-kliënt of 'n aparte VPN-integrasie daarna oplossing skryf nie. Om twee skrywers te onderdruk laat die veld oop eerder as besit. As 'n derde komponent reeds DNS bestuur, verander die fragment niks wat jy kan waarneem nie; as niks dit bestuur nie, het jy pas die enigste bron van private naamoplossing verwyder. Dit is slegs 'n geldige reëling wanneer die plaasvervanger-eienaar eerste gekies en op sy eie getoets is.

Kies die eienaar voordat jy iets deaktiveer

Besluit eerste wie navrae vir werksname beantwoord, want daardie keuse beperk alles daarna. Om die bestaande oplosser te behou beteken die private sone moet reeds bereikbaar wees van waar die kliënt ook sit, en 'n private oplosser binne die kantoor het 'n roete nodig wat die tonnel se opkom oorleef. Om elke navraag na een interne diens te stuur is 'n derde beleid met 'n skerper foutmodus: wanneer daardie diens onbereikbaar is, misluk publieke name saam met die private.

Roete-eienaarskap bly doelbewus apart. Die roete-opsies is nie nodig omdat jy DNS verander het nie, en om roete-installasie af te skakel sonder om 'n plaasvervanger te installeer, kan die oplosser wat jy pas gekies het onbereikbaar maak. Kyk spesifiek in die roetetabel vir die oplosser-adres, nie net vir die toepassing-subnet wat jy toevallig getoets het nie.

Kontroleer oplossing per skakel, nie per lêer nie

'n Enkele /etc/resolv.conf is nie 'n inventaris van wat toepassings werklik gebruik op 'n gasheer met beperkte of per-domein-oplossing nie, so lees die oplosser-toestand soos die platform dit blootlê.

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

Vra een private naam en een publieke naam sodra die verbinding op is, en let op watter skakel elkeen beantwoord het. Waar die VPN-skakel 'n per-domein-soeklys dra, kan 'n private naam korrek oplos terwyl 'n publieke naam steeds na die plaaslike oplosser gaan, en daardie splitsing is die ontwerp wat werk eerder as 'n fout. As die private navraag misluk, ondersoek die roete na die oplosser voordat jy weer aan DNS raak; as dit slaag terwyl 'n toepassing steeds misluk, lees die toepassing dalk 'n gekasde of apart gekonfigureerde oplosser van sy eie.

Herverbind en bevestig die ontkoppelde toestand

Bring die verbinding af en herhaal albei navrae. Wat die gekose eienaar geïnstalleer het, moet deur daardie eienaar verwyder of herstel word, nie deur die kliënt wat jy stilgemaak het agtergelaat nie. 'n Verouderde per-skakel-inskrywing wat die tonnel oorleef, bly private navrae stuur na 'n adres wat nie meer bereikbaar is nie.

Herverbind dan en lees weer dieselfde drie waardes: oplosser-adres, soekdomeine, koppelvlak.

As hulle ooreenstem met die beleid wat jy neergeskryf het, is die oorhandiging voltooi en die VPN-kliënt is nie meer een van die skrywers nie. As 'n waarde 'n paar sekondes ná koppeling terugdryf, pas iets anders steeds konfigurasie toe, en die volgende stap is om daardie komponent te identifiseer eerder as om nog 'n vlag by te voeg. Die eindtoestand wat jy wil hê is onopsienbaar: een eienaar, een gedokumenteerde beleid, en 'n ontkoppelde gasheer wat presies oplos soos voor die tonnel bestaan het.