Katera povezava odgovori: usmerjevalne domene za DNS VPN z razdeljenim tunelom

Običajno brskanje pustite na lokalni povezavi, medtem ko se imena podjetja razrešujejo prek strežnika DNS, ki ga zagotavlja tunel. Izklop privzete poti VPN vam da prvo polovico, drugo pa pusti nezgrajeno. Sledijo nastavitev, ki manjka, ločilo, ki spremeni njen pomen, in edini ukaz, ki pokaže, katera povezava je v resnici odgovorila. Skozi besedilo sta predpostavljena NetworkManager in systemd-resolved, ker se zmeda običajno začne prav pri tem paru.

Prvi korak: ločite pot od razreševalnika

ipv4.never-default odgovori na vprašanje usmerjanja in NetworkManagerju prepreči, da bi to povezavo namestil kot pot za ves promet IPv4. Usmerjevalna domena DNS odgovori na drugo vprašanje: kateri imenski strežniki katere povezave prejmejo poizvedbo za ustrezno pripono. Nobeno ne pomeni drugega, profil pa lahko leta nosi eno, medtem ko drugo manjka. Samo pot pomeni, da tunel prenaša podomrežja podjetja in da njegov razreševalnik odgovarja na imena podjetja, vse ostalo pa ostane nedotaknjeno.

Nastavite samo lastnost poti in notranja imena odpovejo, običajno s časovno omejitvijo, ki zveni kot pokvarjen tunel. Nastavite samo domeno in tiho ste dodali iskalno pripono vsakemu kratkemu imenu na napravi. Obe napaki pošljeta zahtevek na strežnik VPN, ki je le redko del, ki je napačen.

Drugi korak: v profil dodajte domeno samo za usmerjanje

Predpostavite, da se povezava imenuje corp-vpn, pripona podjetja je internal.example, razreševalnik tunela pa je že dosegljiv. Najprej preberite trenutne vrednosti, ker ukazi spodaj spreminjajo lastnosti, ki lahko že imajo vnose.

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

Zamenjajte z lastnim imenom povezave in pripono, ker so zgornje vrednosti zgled. Znak plus je pomembnejši, kot se zdi: z njim se vrednost doda obstoječemu seznamu, brez njega pa se lastnost zamenja in nepovezane domene izginejo iz profila, ki je včeraj deloval. Tilda spremeni vedenje, ne sloga, in odstavek spodaj opisuje, kaj izbere. Ohranite branje pred pisanjem, da vas oblika zamenjave nikoli ne preseneti.

Vodilna tilda označuje domeno samo za usmerjanje, zato poizvedbe, ki se ujemajo, gredo na strežnike te povezave in pripona se kratkim imenom ne doda. Odstranite tildo in isti niz postane tudi iskalna pripona, kar je drug izid, ki ga ljudje redko nameravajo. Obe nastavitvi zgoraj sta IPv4, zato profil z dvojnim skladom potrebuje ipv6.never-default in isto usmerjevalno domeno v ipv6.dns-search, sicer stran IPv6 še naprej uporablja privzeto pot in notranja imena tam odpovejo.

Tretji korak: vprašajte resolvectl, katera povezava je odgovorila

Zaženite resolvectl status in preberite strežnike DNS ter domene vsake povezave, nato zaženite resolvectl query host.internal.example za resnično notranje ime, ki ga smete poizvedovati. Drugi ukaz je edini neposreden dokaz, da usmerjevalna domena opravlja svoje delo, ker imenuje povezavo, ki je odgovorila. Sam seznam stanja dokazuje konfiguracijo; poizvedba dokazuje razrešitev.

systemd-resolved izbere najbolje ujemajočo se usmerjevalno domeno, zato lahko bolj specifična domena na drugi povezavi tekmo še vedno dobi. Če se poizvedba vrne s povezave, ki je niste pričakovali, preberite sezname domen, preden se dotaknete strežnika DNS VPN. Korenska domena ~. se ujema z vsem, in če že obstaja, vaša specifična domena za svoja imena še vedno zmaga, medtem ko povezava odgovori na veliko več, kot ste zahtevali. Odstranite ali zožite ta korenski vnos, ko je bil namen samo imena podjetja.

Če povezava VPN sploh ne navaja strežnika DNS, ga odjemalec ni nikoli registriral. Usmerjevalna domena brez strežnika za seboj odpove drugače kot manjkajoča domena, zato najprej popravite registracijo.

Četrti korak: ko se ime razreši, storitev pa ne

Pravilen odgovor dokazuje le, da je razreševanje delovalo, aplikacija pa še vedno potrebuje pot do prejetega naslova. Ta pot mora preživeti pravkar nastavljeno razdeljeno privzeto pot, zato jo preverite, preden znova obtožite DNS. Nato preverite dosegljivost na vratih storitve, ker skupna raba datotek ali imeniška storitev odpove pri razreševanju, usmerjanju ali preverjanju pristnosti in v vsakem primeru daje zelo podobna sporočila. Te tri plasti imejte ločene, ko poročate o izidu, sicer naslednja oseba znova preverja DNS, ki je bil že pravilen.

Sprememba v Sambini, ki kroži ob tem vprašanju, se tiče dostopne plasti, ne izbire DNS. Uporabiti jo na okvari razreševanja imen je način, kako majhen problem dobi drugega.

Peti korak: razreševalnika ne zamenjajte, da bi popravili manjkajočo domeno

Nasvet, ki prepiše datoteko razreševalnika ali namesti drugega upravitelja razreševalnika, rešuje drug problem. To so spremembe sistemske integracije z lastnimi načini odpovedi in nobena ne doda usmerjevalne domene, ki ni bila nikoli nastavljena. Ugotovite, katera komponenta ima v lasti razreševanje imen na napravi, preden jo zamenjate, ker je na namizju NetworkManager s systemd-resolved to lastništvo že določeno. Boj proti temu je način, kako delujoča nastavitev postane nekaj, česar nihče ne more ponoviti.

Vrstni red dela: potrdite, da tunel zagotavlja razreševalnik, dodajte domeno samo za usmerjanje, znova se povežite prek kontrolnikov profila, preverite povezavo, ki odgovarja, in nato preizkusite storitev na njenih vratih. To zaporedje pusti izid, ki ga lahko predate naslednji osebi brez drugega pogovora.