Tunel deluje, zakaj zasebno ime še vedno ne uspe?

Vse pri povezavi je videti pravilno: tunel deluje in konzola prikazuje zasebno končno točko, a vsaka zahteva ne uspe pri razreševanju imen. Naravna poteza je kriviti tunel, ki se običajno izkaže za nedolžnega. Poizvedba se pošlje strežniku, ki ne ve nič o zasebnem območju. Nobena sprememba usmerjanja ne bo spremenila tega odgovora, ker je težava v tem, koga smo vprašali.

Kateri resolver je prejel poizvedbo?

Poiščite resolver, povezan z vsako povezavo, preden sploh pogledate tunel. Linux prikazuje strežnike za vsako povezavo s ukazom stanja resolverja, macOS pa prikazuje resolverje z obsegom v izpisu konfiguracije DNS. Če odgovor še vedno prihaja iz domačega usmerjevalnika, povezava tunela ni bila nikoli uporabljena.

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

Tu se zamenjujeta dve stopnji: strežnik, ki potiska naslov resolverja, in odjemalec, ki ga namesti na aktivno povezavo. Profil lahko vsebuje možnost in dnevnik lahko kaže, da prihaja, medtem ko operacijski sistem še naprej uporablja stari strežnik. Primerjajte dnevnik s tem, kar poroča povezava, in zaupajte povezavi.

Uporabite naslov, na katerega oblika res odgovarja

Oblačna omrežja običajno odgovarjajo na zasebna imena prek rezerviranega naslova, odmaknjenega za dva od osnove obsega, zato omrežje, ki se začne pri 10.0.0.0, odgovarja na 10.0.0.2. Nekateri ponudniki objavijo tudi lokalni resolver povezave, ki deluje brez poznavanja obsega, kar pomaga, ko je omrežje zgradil nekdo drug. Vprašajte kandidatni naslov neposredno, preden ga potisnete komur koli. Naslov, ki ni resolver, je videti natanko kot zavrnitev požarnega zidu, ker poizvedba preprosto nikoli ne prejme odgovora.

Če neposredna poizvedba odgovori znotraj omrežja, ne pa skozi tunel, je resolver v redu, pot med dvema točkama pa ne. Ta rezultat preusmeri preiskavo na poti, posredovanje in pravila dostopa namesto na profil odjemalca.

Tunel ne prenaša imenskega prostora

Paketi preidejo; imena ne. Vsaki strani je treba povedati, kateri imenski prostor pripada drugi, in to je ločen predmet, ki ga ima tisti, ki drži območje. Običajna oblika je posredovanje za en imenski prostor, usmerjeno na resolver, dosegljiv skozi tunel.

V praksi vsaka smer potrebuje svoje pravilo, ker mora stran, ki ima območje, poizvedbo poslati naprej. Obe smeri zahtevata, da je vir poizvedbe usmerjen in dovoljen, odgovarjajoča stran pa mora odgovore vračati skozi tunel, ne proti internetu. Naj bo posredovanje ozko, tako da je od povezave odvisen samo zasebni imenski prostor. Pošiljanje vsake poizvedbe skozi to spremeni majhno odvisnost v popoln izpad v trenutku, ko tunel pade.

Prehodite meje po vrsti

Preizkusite resolver, nameščen na aktivni povezavi, nato neposredno poizvedbo na ta resolver, nato isto poizvedbo z oddaljene strani in nazadnje aplikacijo, ki uporablja isto ime. Vsak korak izolira eno mejo, zato napaka pove, kam pogledati, namesto da bi preiskavo začeli znova. Odgovor, ki deluje, medtem ko aplikacija ne uspe, kaže na zaupanje v potrdilo ali politiko API, ne na DNS. Te okvare so resnične in nobena sprememba resolverja jih ne bo popravila.

Zapišite, kateri korak je spodletel. Ta ena vrstica je tisto, kar naslednja oseba potrebuje, zapis pa traja deset sekund.

Ohranite verigo tam, kjer jo naslednja oseba najde

Zabeležite potisnjen resolver, pravilo posredovanja, dovoljeni vir poizvedb in odgovarjajočo končno točko na enem mestu. Ko zasebno ime spet ne uspe, zapis pokaže, ali se je tunel premaknil, ali se je naslov resolverja spremenil ali ali je bilo pravilo zoženo. Brez njega se vsak incident začne z nič in konča z istimi tremi ugibanji.

Zapis naj bo dovolj kratek, da ostane točen: štiri vrstice, datum in ime lastnika vsakega dela. Zastarel zapis je slabši od nobenega, ker je videti verodostojen, medtem ko je napačen.