Tunneli on pystyssä, miksi yksityinen nimi silti epäonnistuu?

Kaikki yhteydessä näyttää oikealta: tunneli on pystyssä ja konsoli näyttää yksityisen päätepisteen, mutta jokainen pyyntö epäonnistuu nimien ratkaisussa. Luonnollinen liike on syyttää tunnelia, joka yleensä osoittautuu syyttömäksi. Kysely lähetetään palvelimelle, joka ei tiedä yksityisestä vyöhykkeestä mitään. Mikään reititysmuutos ei muuta sitä vastausta, koska ongelma on siinä, keneltä kysyttiin.

Mille ratkaisijalle kysely päätyi?

Etsi jokaiseen linkkiin liitetty ratkaisija ennen kuin katsot tunnelia lainkaan. Linux näyttää linkkikohtaiset palvelimet ratkaisijan tilakomennolla, ja macOS näyttää rajattuja ratkaisijoita DNS-määrityksen tulosteessa. Jos vastaus tulee yhä kotireitittimeltä, tunnelilinkkiä ei koskaan kysytty.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Tässä sekoittuu kaksi vaihetta: palvelin, joka työntää ratkaisijan osoitteen, ja asiakas, joka asentaa sen aktiiviselle linkille. Profiili voi sisältää asetuksen, ja loki voi näyttää sen saapuvan, kun taas käyttöjärjestelmä jatkaa vanhan palvelimen käyttöä. Vertaa lokia siihen, mitä linkki ilmoittaa, ja luota linkkiin.

Käytä osoitetta, johon pilviverkko todella vastaa

Pilviverkot vastaavat yksityisiin nimiin yleensä varatulla osoitteella, joka on kaksi askelta alueen perustan yläpuolella, joten verkko, joka alkaa osoitteesta 10.0.0.0, vastaa osoitteessa 10.0.0.2. Jotkut tarjoajat julkaisevat myös linkkipaikallisen ratkaisijan, joka toimii aluetta tuntematta, mikä auttaa, kun verkon on rakentanut joku muu. Kysy ehdokasosoitetta suoraan ennen kuin työnnät sen kenellekään. Osoite, joka ei ole ratkaisija, näyttää täsmälleen palomuurin pudotukselta, koska kysely ei yksinkertaisesti saa koskaan vastausta.

Jos suora kysely vastaa verkon sisältä mutta ei tunnelin yli, ratkaisija on kunnossa ja kahden pisteen välinen polku ei. Tulos siirtää tutkinnan reitteihin, välitykseen ja käyttösääntöihin asiakasprofiilin sijaan.

Tunneli ei kanna nimiavaruutta

Paketit kulkevat; nimet eivät. Kummallekin puolelle on kerrottava, mikä nimiavaruus kuuluu toiselle, ja se on erillinen objekti, jonka omistaa se, joka pitää vyöhykettä. Tavallinen muoto on välitys yhdelle nimiavaruudelle, suunnattuna ratkaisijaan, joka on tavoitettavissa tunnelin kautta.

Käytännössä kumpikin suunta tarvitsee oman sääntönsä, koska vyöhykkeen omistava puoli lähettää kyselyn eteenpäin. Molemmat suunnat vaativat, että kyselyn lähde reititetään ja sallitaan, ja vastaavan puolen on palautettava vastaukset tunnelin kautta eikä internettiin. Pidä välitys kapeana, niin että vain yksityinen nimiavaruus riippuu linkistä. Kaikkien kyselyjen lähettäminen sen läpi muuttaa pienen riippuvuuden täydelliseksi katkokseksi hetkellä, jolloin tunneli kaatuu.

Käy rajat läpi järjestyksessä

Testaa aktiiviselle linkille asennettu ratkaisija, sitten suora kysely sille ratkaisijalle, sitten sama kysely kauemmalta puolelta ja lopuksi sovellus, joka käyttää samaa nimeä. Jokainen askel eristää yhden rajan, joten vika kertoo, mihin katsoa, sen sijaan että tutkinta aloitettaisiin alusta. Vastaus, joka toimii sovelluksen epäonnistuessa, viittaa varmenteen luottamukseen tai API-käytäntöön eikä DNS:ään. Ne viat ovat todellisia, eikä mikään ratkaisijan muutos korjaa niitä.

Kirjoita ylös, mikä vaihe epäonnistui. Se yksi rivi on se, mitä seuraava henkilö tarvitsee, ja sen kirjaaminen kestää kymmenen sekuntia.

Pidä ketju siellä, mistä seuraava henkilö löytää sen

Kirjaa työnnetty ratkaisija, välityssääntö, sallittu kyselyn lähde ja vastaava päätepiste yhteen paikkaan. Kun yksityinen nimi epäonnistuu taas, merkintä näyttää, siirtyikö tunneli, muuttuiko ratkaisijan osoite vai kavennettiinko sääntöä. Ilman sitä jokainen tapaus alkaa nollasta ja päättyy samoihin kolmeen arvaukseen.

Pidä merkintä riittävän lyhyenä pysyäkseen tarkkana: neljä riviä, päivämäärä ja jokaisen osan omistajan nimi. Vanhentunut merkintä on huonompi kuin ei mitään, koska se näyttää arvovaltaiselta ollessaan väärä.