Tunel radi, pa zašto privatno ime i dalje ne uspijeva?

Sve na vezi izgleda ispravno: tunel radi i konzola prikazuje privatnu krajnju točku, ali svaki zahtjev pada na razrješavanju imena. Prirodan potez je kriviti tunel, koji se obično pokaže nevinim. Upit se šalje serveru koji ne zna ništa o privatnoj zoni. Nikakva promjena rute neće promijeniti taj odgovor, jer problem je koga smo pitali.

Koji resolver je dobio upit?

Pronađite resolver vezan za svaku vezu prije nego što uopće pogledate tunel. Linux prikazuje servere po vezi kroz naredbu za status resolvera, a macOS prikazuje resolvere s opsegom u ispisu DNS konfiguracije. Ako odgovor još dolazi od kućnog rutera, veza tunela nikada nije bila konsultovana.

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

Ovdje se miješaju dvije faze: server koji gura adresu resolvera i klijent koji je instalira na aktivnu vezu. Profil može sadržavati opciju, a dnevnik može pokazati da dolazi, dok operativni sistem nastavlja koristiti stari server. Uporedite dnevnik s onim što veza prijavljuje i vjerujte vezi.

Koristite adresu na koju cloud mreža zaista odgovara

Cloud mreže obično odgovaraju na privatna imena preko rezervirane adrese pomjerene za dva od osnove raspona, pa mreža koja počinje na 10.0.0.0 odgovara na 10.0.0.2. Neki provajderi objavljuju i link-local resolver koji radi bez poznavanja raspona, što pomaže kada je mrežu izgradio neko drugi. Pitajte kandidatsku adresu izravno prije nego što je pošaljete bilo kome. Adresa koja nije resolver izgleda točno kao firewall drop, jer upit jednostavno nikada ne dobije odgovor.

Ako izravni upit odgovara iz mreže, ali ne preko tunela, resolver je ispravan, a put između dvije točke nije. Taj rezultat pomjera istragu na rute, prosljeđivanje i pravila pristupa, a ne na profil klijenta.

Tunel ne nosi prostor imena

Paketi prelaze; imena ne. Svakoj strani treba reći koji prostor imena pripada drugoj, a to je zaseban objekt koji posjeduje onaj koji drži zonu. Uobičajen oblik je prosljeđivanje za jedan prostor imena, usmjereno na resolver dostupan preko tunela.

U praksi svaki smjer treba svoje pravilo, jer strana koja posjeduje zonu mora poslati upit dalje. Oba smjera zahtijevaju da izvor upita bude rutiran i dozvoljen, a strana koja odgovara mora vraćati odgovore kroz tunel, a ne prema internetu. Držite prosljeđivanje uskim, tako da samo privatni prostor imena zavisi od veze. Slanje svakog upita kroz nju pretvara malu zavisnost u potpuni prekid u trenutku kada tunel padne.

Prođite granice po redu

Testirajte resolver instaliran na aktivnoj vezi, zatim izravni upit na taj resolver, zatim isti upit s druge strane i na kraju aplikaciju koja koristi isto ime. Svaki korak izolira jednu granicu, pa neuspjeh govori gdje tražiti umjesto da počinje istragu iznova. Odgovor koji radi dok aplikacija ne uspijeva upućuje na povjerenje u certifikat ili API pravilo, a ne na DNS. Ti su kvarovi stvarni i nikakva promjena resolvera ih neće popraviti.

Zapišite koji je korak neuspješan. Taj jedan redak je ono što sljedećoj osobi treba, a zapisivanje traje deset sekundi.

Držite lanac tamo gdje ga sljedeća osoba može pronaći

Zabilježite gurnuti resolver, pravilo prosljeđivanja, dozvoljeni izvor upita i krajnju točku koja odgovara na jednom mjestu. Kada privatno ime ponovno ne uspije, zapis pokazuje je li se tunel pomaknuo, adresa resolvera promijenila ili je pravilo suženo. Bez njega svaki incident počinje od nule i završava s iste tri pretpostavke.

Držite zapis dovoljno kratkim da ostane točan: četiri retka, datum i ime onoga koji posjeduje svaki dio. Zastario zapis je gori od nikakvog, jer izgleda autoritativno dok je pogrešan.