VPN-isäntänimet epäonnistuvat, IP-osoitteet toimivat: mistä katsoa

Voit avata jaon osoitteella, ja sama jako nimellä epäonnistuu, mikä tarkoittaa, että tunneli kuljettaa paketteja eikä nimikerros. Tämä yksi havainto säästää kiertotien palomuurin ja reittien muutosten kautta. Nimet tarvitsevat suffiksin, ratkaisimen ja polun kyselylle, ja VPN-asiakas voi asentaa reitin asentamatta mitään niistä. Käy alla olevat neljä tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, joka murtuu.

Nimi kysyy kysymyksen, jota osoite ei kysy

Osoite on kohde, jota pino voi käyttää heti. Lyhyt nimi on kysymys, joka on laajennettava suffiksilla, lähetettävä ratkaisimelle ja vastattava jollakin, joka tuntee vyöhykkeen. Tunneli, joka asentaa reitit mutta ei ratkaisinta, jättää ensimmäisen toimimaan ja toisen rikki. Siksi oire näyttää niin johdonmukaiselta hyvin erilaisissa VPN-tuotteissa.

Työskentele osoitteesta ulospäin: ensin koko nimi, sitten paljas isäntänimi, ja kirjaa, mikä kolmesta toimii. Kuvio kertoo, mitä kerrosta tutkia ennen kuin avaat yhtäkään asetusnäkymää. Reittien arvaaminen, kun FQDN ratkeaa, on hukattua vaivaa.

Lue ratkaisin, jonka tunneli todella asensi

Kysy käyttöjärjestelmältä mikä ratkaisin käsittelee sisäisen vyöhykkeen kyselyt, älä sitä, minkä VPN-asiakkaan liitäntä ilmoittaa. Palvelin, joka työntää julkisen ratkaisimen ilman sisäistä vyöhykettä, tuottaa juuri tämän epäonnistumisen, ja se on asetusvirhe eikä reititysvika.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Toimialueeseen liitetyssä Windows-asiakkaassa nimiavaruuden reitityskäytäntö päättää, mitkä kyselyt menevät millekin ratkaisimelle, ja VPN-sovittimen omat DNS-asetukset näkyvät sovittimen tiedoissa. Lue voimassa oleva käytäntö, älä profiilia, koska välimuistiin jäänyt käytäntö voi elää kauemmin kuin sen asentanut yhteys. Jos ratkaisin vastaa koko nimeen eikä lyhyeen nimeen, ongelma on jo siirtynyt suffiksiluetteloon.

Get-DnsClientNrptPolicy
ipconfig /all

Pysähdy, jos sisäinen vyöhyke ratkeaa oikean palvelimen kautta. Ratkaisin ei ole ongelmasi.

Suffiksit selittävät lyhyet nimet, jotka epäonnistuvat

Yhden tunnisteen nimi laajennetaan yhteyden suffiksiluettelolla ennen kyselyn lähettämistä. Jos VPN ei toimita sisäistä suffiksia, fileserveristä ei koskaan tule fileserver.corp.example, ja kysely lähtee nimenä, jota mikään julkinen ratkaisin ei tunne. Suffiksin työntäminen tai koko nimen kirjoittaminen testaa hypoteesin muuttamatta palvelimella mitään.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linuxissa ratkaisinpalvelu sitoo DNS-palvelimen linkkiin ja joukkoon reititystoimialueita, joten työnnetty palvelin, joka ei liity tunnelin linkkiin, käyttäytyy kuin sitä ei olisi. Tarkista tila linkeittäin äläkä stub-tiedostoa, joka voi osoittaa vain paikalliseen ratkaisimeen. Sama jakautuminen näkyy toiseen suuntaan: hakutoimialue, joka on olemassa mutta jota ei sovelleta tunnelin liitäntään, tuottaa lyhyiden nimien epäonnistumisia, jotka näyttävät satunnaisilta.

Jos suffiksin lisääminen korjaa sen, jäljellä on toimittaa tuo suffiksi VPN-profiilin kautta sen sijaan, että jokaiselta käyttäjältä pyydettäisiin sen kirjoittamista.

NetBIOS ja WINS ovat toinen mekanismi

Vanha SMB voi yhä etsiä paljaan nimen NetBIOS-nimipalvelulla, joka vastaa lähetyksellä tai WINS-palvelimen kautta. Lähetys pysyy yhden lähetystoimialueen sisällä ja pysähtyy ensimmäiseen reitittimeen, joten se ei voi ylittää tunnelia; WINS toimii, koska asiakkaalla on unicast-osoite, johon rekisteröityä ja jota kysyä. Siksi vain IP:tä kuljettava VPN voi yhä tukea vanhoja nimiä, kun WINS on määritetty ja saavutettavissa.

nbtstat -n
nbtstat -R

Nykyaikaiselle SMB:lle luota DNS-palveluun ja koko nimeen ja siirrä vanha polku eläkkeelle. Jos se on aidosti vanha, tarjoa WINS tai korvaa sovellus; keskitie on tukijono, joka ei koskaan tyhjene.

Läpikäynti päättyy, kun voit sanoa, mikä kerros petti: ratkaisin, suffiksi vai vanha löytö. Kirjaa ratkaisin, joka vastasi, ja nimimuoto, joka toimi, koska seuraava henkilö aloittaa samasta oireesta.