Watter skakel antwoord: roeteringdomeine vir split-tonnel-VPN-DNS

Hou gewone blaai op die plaaslike skakel terwyl maatskappyname deur die DNS-bediener oplos wat die tonnel verskaf. Om die VPN se standaardroete af te skakel, gee jou die eerste helfte en laat die tweede helfte ongebou. Wat volg, is die ontbrekende instelling, die leesteken wat verander wat dit beteken, en die een opdrag wat wys watter skakel werklik geantwoord het. NetworkManager en systemd-resolved word deurgaans veronderstel, want daardie paar is waar die verwarring gewoonlik begin.

Stap een: skei die roete van die oplosser

ipv4.never-default beantwoord ’n roetevraag en keer dat NetworkManager hierdie verbinding as die pad vir alle IPv4-verkeer installeer. ’n DNS-roeteringdomein beantwoord ’n ander vraag: watter skakel se naambedieners ’n navraag vir ’n passende suffix ontvang. Nie een impliseer die ander nie, en ’n profiel kan jare lank een dra terwyl die ander ontbreek. Slegs-roete beteken die tonnel dra maatskappy-subnette en sy oplosser beantwoord maatskappyname, terwyl alles anders alleen gelaat word.

Stel net die roete-eienskap en interne name misluk, gewoonlik met ’n tydsverloop wat soos ’n stukkende tonnel lyk. Stel net die domein en jy het stilletjies ’n soeksuffix by elke kort naam op die masjien gevoeg. Albei foute stuur die kaartjie na die VPN-bediener, wat selde die deel is wat verkeerd is.

Stap twee: voeg ’n slegs-roetering-domein by die profiel

Veronderstel die verbinding heet corp-vpn, die maatskappysuffix is internal.example, en die tonnel se oplosser is reeds bereikbaar. Lees eers die huidige waardes, want die opdragte hieronder verander eienskappe wat reeds inskrywings kan bevat.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Vervang jou eie verbindingsnaam en suffix, want die waardes hierbo is illustratief. Die plusteken maak meer saak as wat dit lyk: daarmee word die waarde by die bestaande lys gevoeg, terwyl die eienskap sonder dit vervang word en onverwante domeine verdwyn uit ’n profiel wat gister nog gewerk het. Die tilde verander gedrag eerder as styl, en die paragraaf hieronder dek wat dit kies. Hou die lees voor die skryf, sodat die vervangingsvorm jou nooit verras nie.

’n Voorste tilde merk ’n slegs-roetering-domein, so passende navrae gaan na hierdie skakel se bedieners en die suffix word nie by kort name gevoeg nie. Laat die tilde weg en dieselfde string word ook ’n soeksuffix, wat ’n ander uitkoms is wat mense selde bedoel. Albei instellings hierbo is IPv4, so ’n dubbelstapel-profiel benodig ipv6.never-default en dieselfde roeteringdomein in ipv6.dns-search, anders bly die IPv6-kant die standaardroete gebruik en misluk interne name daar.

Stap drie: vra resolvectl watter skakel geantwoord het

Voer resolvectl status uit en lees elke skakel se DNS-bedieners en domeine, en voer dan resolvectl query host.internal.example uit teen ’n werklike interne naam wat jy mag navraag doen. Die tweede opdrag is die enigste direkte bewys dat die roeteringdomein sy werk doen, want dit noem die skakel wat geantwoord het. ’n Statuslys alleen bewys konfigurasie; die navraag bewys oplossing.

systemd-resolved kies die beste passende roeteringdomein, so ’n meer spesifieke domein op ’n ander skakel kan steeds die wedloop wen. As die navraag van ’n skakel terugkom wat jy nie verwag het nie, lees die domeinlyste voordat jy aan die VPN se DNS-bediener raak. ’n Worteldomein van ~. pas alles, en as dit reeds teenwoordig is, wen jou spesifieke domein steeds vir sy eie name terwyl die skakel veel meer antwoord as wat jy gevra het. Verwyder of vernou daardie wortelinskrywing wanneer die bedoeling net maatskappyname was.

As die VPN-skakel glad geen DNS-bediener lys nie, het die kliënt nooit een geregistreer nie. ’n Roeteringdomein sonder ’n bediener agter hom misluk anders as ’n ontbrekende domein, so maak eers registrasie reg.

Stap vier: wanneer die naam oplos maar die diens nie

’n Korrekte antwoord bewys net dat oplossing gewerk het, en die toepassing benodig steeds ’n roete na die adres wat dit ontvang het. Daardie roete moet die gesplete standaard oorleef wat jy pas opgestel het, so gaan dit na voordat jy DNS weer blameer. Gaan dan bereikbaarheid op die diens se poort na, want ’n lêerdeel of gidsdiens misluk op oplossing, roetering of verifikasie en lewer in elke geval baie soortgelyke boodskappe. Hou daardie drie lae apart wanneer jy die uitkoms rapporteer, anders herkontroleer die volgende persoon DNS wat reeds korrek was.

Die Samba-verandering wat saam met hierdie vraag sirkuleer, spreek die toegangslag aan, nie die DNS-keuse nie. Om dit op ’n naamoplossingsfout toe te pas, is hoe ’n klein probleem ’n tweede een kry.

Stap vyf: moenie die oplosser vervang om ’n ontbrekende domein reg te maak nie

Raad wat die oplosserlêer oorskryf of ’n ander oplosserbestuurder installeer, los ’n ander probleem op. Dit is stelselintegrasieveranderings met hul eie foutmodusse, en nie een van hulle voeg ’n roeteringdomein by wat nooit opgestel is nie. Stel vas watter komponent naamoplossing op die masjien besit voordat jy dit vervang, want op ’n NetworkManager-lessenaar met systemd-resolved is daardie eienaarskap reeds gedefinieer. Om daarteen te veg, is hoe ’n werkende opstelling iets word wat niemand kan reproduseer nie.

Orde van werk: bevestig die tonnel verskaf ’n oplosser, voeg die slegs-roetering-domein by, herverbind deur die profiel se kontroles, verifieer die antwoordende skakel, en toets dan die diens op sy poort. Daardie volgorde laat ’n resultaat wat jy aan die volgende persoon kan oorhandig sonder ’n tweede onderhoud.