A LAN-gépnév nem működik VPN-en át: utótag, mDNS vagy zóna?

Az eszköz mellett a nyomtató egy rövid névre, a fájlszerver pedig egy becenévre válaszol. Az alagúton át mindkét név lejár, miközben a címük továbbra is működik. Az útvonal végzi a dolgát; a névfeloldási útvonal, amely működőképessé tette ezeket a rövid neveket, soha nem kelt át az alagúton. Három mechanizmus hozza létre ezt a viselkedést, és mindegyik más javítást igényel.

Kezdje azzal, hogy megállapítja, melyik mechanizmustól függ a név.

Háromféle név, amelyek másként viselkednek

Az egycímkés név, például a fileserver, általában a feloldó által hozzáfűzött DNS-keresési utótagra támaszkodik. Ez az utótag gyakran a helyi DHCP-bérlettel érkezik, így a VPN-től címzést kapó távoli kliensnek nincs oka ismerni. Egy útvonal hozzáadása nem szállítja az utótagot. A rövid név egyszerűen megszűnik névként létezni, pedig a mögötte lévő cím elérhető.

A .local végződésű nevet általában multicast DNS oldja fel a helyi kapcsolaton, ahogy az RFC 6762 leírja. A multicast nem halad át irányított alagúton, hacsak valami szándékosan át nem hidalja vagy proxyn nem továbbítja, ezért a név abban a pillanatban megszűnik feloldódni, amikor elhagyja a szegmenst.

A teljesen minősített cégnév egy belső zónához tartozik, amelyet a szervezet feloldói szolgálnak ki. Az távolról akkor működik, ha a VPN leküldi ezeket a feloldókat, és a kliens úgy van beállítva, hogy használja őket. És a localhost az RFC 6761 szerint különleges célú: az Ön előtti gépre utal, soha nem távoli szolgáltatásra.

Olvassa el a feloldót, mielőtt megváltoztatja az útvonalat

Kérdezze meg, melyik névszerver válaszolt, és melyik utótagot fűzte hozzá. Ugyanaz a lekérdezés különböző feloldókon keresztül különböző válaszokat ad, és ez a különbség a szükséges bizonyíték.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Ha a teljesen minősített lekérdezés feloldódik, a rövid viszont nem, a hiba az utótagban van, nem a szerverben. Ha egyik sem oldódik fel, és a cím működik, a kliens egyáltalán nem használja a belső feloldót. Hasonlítsa össze a feloldók listáját azzal, amit a VPN-nek le kellene küldenie, mert az a kliens, amely minden lekérdezéshez megtartja a helyi feloldóját, soha nem fogja látni a belső zónát.

Vigye el a helyes nevet a klienshez

Kérje meg az adminisztrátortól a dokumentált távoli hozzáférési nevet, teljes egészében, és használja azt a profilban az utótagok találgatása helyett. Ha a telepítés támogatja a split DNS-t, állítsa be, hogy a belső tartományt a belső szerverek oldják fel, miközben minden más megtartja a helyi feloldót. Küldje le a keresési tartományt a VPN-konfiguráción keresztül ott, ahol a kliens támogatja.

Ellenőrizze az eredményt a kliensen, ne az átjárón. Egy szerveren alkalmazott beállítás, amely soha nem ér el a klienshez, semmit sem változtat.

Őrizze meg a tanúsítvány identitását

A címre épülő teszt, amely figyelmen kívül hagyja a tanúsítvány hibáját, csak azt bizonyítja, hogy a foglalat megnyílt. A szolgáltatás tanúsítványa egy névre van kiállítva, és a kliens jó okkal továbbra is elutasítja az eltérést. Ha a tanúsítvány csak a belső nevet sorolja fel, használja azt a nevet, és javítsa a feloldást, vagy szerezzen olyan tanúsítványt, amely lefedi a használni kívánt címet.

Jegyezze fel a nevet, a feloldót és az utótagot, amelyek sikeres kapcsolatot eredményeztek. Ez a feljegyzés megkíméli a következő embert attól, hogy megismételje a címalapú kerülőutat, amely elrejti az igazi problémát.