Miért old fel az nslookup VPN-en át, a böngésző mégsem

Az nslookup lekérdezést küld a megnevezett kiszolgálónak, és kiírja a választ, ezért sikerülhet, miközben a böngésző minden lapja meghiúsul. A böngésző az operációs rendszertől kér feloldást, az operációs rendszer pedig mérlegeli az interfészenkénti feloldókat, a névfeloldási házirend szabályait és az adapter hálózati helyét. Ezután a böngésző a saját titkosított DNS-ét is ráteheti. Három különböző útvonal, egy tünet, és az alagút általában nem a hibás rész.

Az alábbi ellenőrzések ezeket az útvonalakat követik a rendszertől kifelé. Ne szerkessze a VPN-profilt, amíg nem tudja, melyik útvonal válaszolt és melyik hibázott.

Három házirend dönt a válaszról

Minden interfész saját feloldólistát és keresési utótagokat hordoz. A VPN-adapter kiszolgálókat ad hozzá, miközben a fizikai adapter megtartja a sajátjait, és a rendszer azt veheti, amelyik először válaszol, így egy keresés az alagúton kívül is kiszolgálható anélkül, hogy bárki ezt választotta volna. A névfeloldási házirend táblázatának szabályai kiválasztott tartományokat küldhetnek kiválasztott kiszolgálókra, így szokás a split DNS-t Windows alatt kifejezni. A VPN-kliens vagy az átjáró pedig olyan feloldócímet küldhet, amely csak a magánhálózaton belül létezik.

Ez a három olyan módokon hat egymásra, amelyek a böngészőből önkényesnek tűnnek. A split alagúton át vezető útvonal nélküli magáncímre küldött feloldó minden keresést megakaszt, majd meghiúsít. A belső utótagot lefedő és leállt kiszolgálóra mutató házirendszabály ugyanazt a látható hibát adja, mint a hiányzó útvonal. A VPN-adapterről hiányzó keresési utótag a rövid nevet nyilvános lekérdezéssé teszi a rossz tartományra. Mindegyik más javítást igényel.

Miért tesz fel a böngésző más kérdést

Az nslookup a saját lekérdezését küldi a választott kiszolgálónak, és nem követi sem a névtér-házirendet, sem a böngésző titkosított DNS-beállítását. Ezért válaszol egy nyilvános feloldóhoz intézett kézi lekérdezés, miközben a böngésző azt jelenti, hogy az oldal nem létezik. Két programot hasonlít össze, nem egy program két állapotát.

A címcsalád-preferencia késést magyaráz, nem hibát. Az a böngésző, amely csak IPv4-et vivő alagúton először IPv6-rekordokat kér, megvárja az időtúllépést, mielőtt visszalép. A Firefox éppen erre tartott preferenciát, és ennek kikapcsolása diagnosztikai lépés, nem javítás.

Olvassa el a feloldólistát és a szabályokat

Windows alatt írja ki, mit tart a rendszer, mielőtt elméleteket gyárt. A Get-DnsClientServerAddress interfészenként mutatja a kiszolgálókat, a Get-DnsClientNrptRule felsorolja a névtér-szabályokat, a Resolve-DnsName pedig a rendszer útvonalán válaszol a pontos névre. Hasonlítsa össze ezt a választ a VPN kiszolgálójának cím szerinti közvetlen lekérdezésével. Amikor a Resolve-DnsName meghiúsul, a közvetlen lekérdezés pedig sikerül, a gyanúsított a feloldólista vagy egy névtér-szabály.

Ellenőrizze magát a nevet is. Egy belső rövid névnek szüksége lehet arra a magán-utótagra, amelyet csak a VPN-adapter ad, miközben a teljesen minősített név jól feloldódik. A sikeres keresés utáni tanúsítványfigyelmeztetés más problémához tartozik.

Az elérhetetlen küldött feloldó

Az átjáró vagy a kliens küldhet feloldócímet, és ennek a címnek elérhetőnek kell lennie az alagúton át. Split alagút esetén előfordulhat, hogy a feloldót tartalmazó magántartomány nincs a belefoglalt útvonalak között, ami olyan keresést eredményez, amely soha nem kap választ. Erősítse meg, hogy az útvonal létezik, majd kérdezze meg pontosan azt a címet az alagúton át. Ez a hiba áll a böngésző tartományhibája mögött, miközben egy nyilvános feloldó még válaszol.

Ha a feloldó elérhetetlen, a javítás útvonal vagy belefoglalt alhálózat, nem másik DNS-kiszolgáló.

A titkosított DNS megkerüli a teljes útvonalat

A DNS-over-HTTPS-t használó böngészők maguk oldják fel a neveket egy választott szolgáltatóhoz intézett HTTPS-kapcsolaton. Ha ez be van kapcsolva, a rendszer feloldója és a split DNS szabályai teljesen megkerülődnek ezeknél a kereséseknél, így a belső nevek meghiúsulnak a böngészőben, miközben az operációs rendszer helyesen feloldja őket. Fordítva is előfordul: belső nevek sikerülnek a böngészőben egy olyan szolgáltatón át, amelynek soha nem lett volna szabad látnia őket, és ez házirend-, nem kapcsolódási probléma.

Döntse el tudatosan, hogy engedélyezett-e a titkosított DNS a felügyelt eszközökön, majd állítsa be a böngésző felügyeleti felületén, hogy a választás látható legyen. Ha egyéni preferenciára bízza, olyan flotta lesz belőle, amelyben ugyanaz a VPN minden laptopon másként viselkedik.

A hibához illő javítások

Ha a VPN küldi a feloldóját, tegye elérhetővé számára a forgalmat az alagúton, és tegye láthatóvá ugyanazt a beállítást azokon az adaptereken, amelyek részt vesznek a feloldásban. Ha csatlakozás közben a helyi oldalak feloldása leáll, adjon hozzá kifejezett névtér-kivételeket vagy feltételes továbbítót a feloldó teljes lecserélése helyett. Ha a böngésző titkosított DNS-e megkerüli a házirendet, az a beállítás, amit módosítani kell. Soha ne adjon hozzá nyilvános feloldót egy belső név javításához: kiszivárogtatja a magánlekérdezéseket, és nem oldja fel a nevet.

Ezután válassza szét a keresést a kapcsolattól. Az a név, amely a helyes címre oldódik fel, de megtagadja a kapcsolatot, szolgáltatási, tűzfal- vagy tanúsítványprobléma, és a DNS-változtatások nem javítják.

Jegyezze fel, melyik útvonal válaszolt, melyik hibázott és mit változtatott. A következő, ugyanerről a tünetről szóló jelentés aztán egy parancsba kerül egy délután helyett.