A VPN alatt a belső nevek nem oldódnak fel, a nyilvános oldalak igen

Egy felhasználó jelenti, hogy az intranet hosztnév nem oldódik fel a VPN alatt. Egy második jelentés, ugyanarról a laptopról, azt mondja, hogy a szivárgásteszt továbbra is a helyi feloldó válaszait mutatja. Egy problémának hangzanak, pedig kettő, eltérő bizonyítékokkal, és az első szokásos javítása rontja a másodikat. Válassza szét őket, mielőtt bármelyik beállításhoz nyúl.

Két tünet, amely nem egy hiba

Egy belső név feloldásának kudarca azt jelenti, hogy a kérdés olyan helyre ment, ahol nincs rá válasz. Az alagútból kilépő lekérdezések azt jelentik, hogy a kérdés rossz helyre ment akkor is, amikor a válasz elérhető volt. Ezek ellentétes hibák: az egyikben hiányzik a válasz, a másikban van egy felesleges cél.

A csapda az, hogy az irodai feloldó mindenhol való hozzáadása javítja az elsőt és garantálja a másodikat. Egy nyilvános feloldó mindenhol való hozzáadása az ellenkezőjét teszi.

Írja fel mindkét megfigyelést időbélyeggel, majd menjen végig sorrendben az alábbi négy ellenőrzésen.

Melyik adapter feloldója kapja a kérdést

Windows alatt a DNS-kliens az adapterek kötési sorrendje szerint választ kiszolgálókat, és az alagút-adapter nem automatikusan az első. Nyissa meg az adapter speciális beállításait, és mozgassa a távoli hozzáférési kapcsolatot a fizikai adapter fölé, majd kapcsolódjon újra, hogy a változás új munkamenetre érvényesüljön.

A kötési sorrend csak az első fele. A kliensnek azt is tudnia kell, mely nevek tartoznak ahhoz az adapterhez, és ez utótag-kérdés, nem sorrendkérdés.

Tegye a ipconfig /all kimenetét a laptopé mellé, mindkettőt az alagút aktív állapotában. A működő gép egy kapcsolatspecifikus DNS-utótagot fog mutatni az irodai adapterén, a laptop pedig talán semmit az alagúton. Ez a különbség magyarázza azoknak a jelentéseknek az egész osztályát, amelyek szerint a kiszolgáló ott van, a név mégis meghiúsul, mert utótag nélkül a rövid név soha nem egészül ki arra a zónára, amelyet az irodai feloldó kiszolgál.

A rövid névnek utótag kell, mielőtt útvonal kellene

Egy minősítés nélküli hosztnév beírása arra kéri a feloldót, hogy találjon ki egy tartományt. A tipp a kapcsolathoz csatolt utótaglistából jön, és ha az a lista üres, a lekérdezés egyetlen címkeként megy ki, amelyre egyetlen privát zóna sem fog illeszkedni.

Másolja a működő gép utótagját a VPN-adapter IPv4-tulajdonságaiba a DNS lapon, majd kapcsolódjon újra. Linuxon a megfelelő a keresési tartomány az alagút linkjén, amelyet a systemd-resolved linkenként tesz elérhetővé, nem globálisan.

Tartsa a két beállítást külön a jegyzeteiben. Az utótag azt változtatja meg, hogy mit kérdezünk; a feloldó címe azt, hogy kit kérdezünk. Az egyik javítása, miközben a másik hibás, véletlenszerűnek látszó eredményt ad.

Kérdezze meg közvetlenül a feloldót, aztán a nevet

Közvetlen lekérdezés az irodai feloldóhoz elválasztja a névproblémát az útvonalproblémától, mert teljesen megkerüli a kliens feloldóválasztását.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Az első parancs egy adott kiszolgálótól kér egy teljesen minősített nevet. Ha válaszol, a feloldó és a hozzá vezető útvonal rendben van, és a hiba a választásban vagy az utótagban van. Ha időtúllépés történik, a cím hibás vagy elérhetetlen, és a probléma útvonalválasztási, nem DNS. A második parancs megmutatja, mi történik a rövid névvel, a harmadik pedig kinyomtatja a linkenkénti feloldókonfigurációt egy systemd-s gazdagépen.

Figyeljen a helyettesítő válaszokra, amelyeket egyes hálózatok ismeretlen nevekre adnak vissza. A hihetőnek tűnő válasz nem bizonyítja, hogy a szándékolt kiszolgáló válaszolt, ezért hasonlítsa össze a visszaadott címet azzal, amelyet a belső szolgáltatás valóban használ. Ha a cím egy parkolóoldalhoz vagy proxyhoz tartozik, a feloldó válaszolt, de a válasz soha nem a magáé volt. Ez a megkülönböztetés egy órányi kutatást spórol meg egy olyan alagút után, amely végig működött.

Linuxon az a VPN-kliens, amely átírja a /etc/resolv.conf fájlt, teljesen lecseréli a helyi feloldókat. A vpnc ezt a DNSUpdate no beállítással akadályozza meg, a systemd-resolved pedig csak a felsorolt tartományokat tudja az alagút linkjére irányítani. Mindkét megközelítés a helyi feloldón tartja a nyilvános neveket, miközben a belső neveket az irodába küldi.

A szivárgás szabály, nem jelölőnégyzet

A névfeloldás UDP-csere az 53-as porton, ezért az az alagút, amely webes forgalmat visz, de UDP-t nem, a fizikai útvonalon hagyja a lekérdezést. Bizonyítsa ezt a fizikai hálózati kártyán végzett rögzítéssel, miközben egy nyilvános nevet old fel. Az azon a felületen olvasható formában látható lekérdezés azt jelenti, hogy az alagút nem viszi.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Ha a lekérdezés olvasható formában megjelenik azon a felületen, az alagút nem viszi. A javítás egy szabály, amely az 53-as portot csak a VPN által küldött feloldónak engedi, a többi célt pedig eldobja, valamint egy klienskonfiguráció, amely nem dobja el csendben a küldött beállítást.

Ez az utolsó rész fontosabb, mint amilyennek látszik. Indítsa az OpenVPN-t ezzel: route-nopull és a küldött DNS-beállítás eltűnik az útvonalakkal együtt, hacsak a húzási szűrőt ki nem szélesítik, hogy megtartsa. és egy kliens, amely figyelmen kívül hagyja a dhcp-option DNS beállítást, továbbra is azt használja, ami korábban volt. A kiszolgáló oldalán minden változtatáshoz új munkamenet kell, mert a feloldólista az alagút felépülésekor érkezik, és az elavult munkamenet a régi állapotot mutatja.

Jegyezze fel, melyik hibát látta valójában a jegy lezárása előtt. A hiányzó belső válasz és az alagútból kiszökő lekérdezés különböző javításokat kíván, és az elsőt javító utótagváltozás csendben ronthatja a másodikat. A következő, aki átveszi a jegyet, a címkének fog hinni, ezért tegye pontossá a címkét.