Privatno ime razrješava se s instance EC2, ali ne s prijenosnika povezanog preko VPN-a, a zona u konzoli izgleda ispravno. Nagon je urediti zapis, što gotovo nikad nije problem. Zapis nekome odgovara; samo ne odgovara vašem prijenosniku. Ono što se razlikuje između dva pozivatelja jest koji resolver pitaju i ima li taj resolver podržan put u DNS pogled unutar VPC-a.

Počinjem dokazivanjem da zapis postoji, a ostatak vremena posvećujem putu upita. To su odvojeni sustavi i otkazuju na različite načine.

Pročitajte oblik kvara prije nego što išta promijenite

Tri ishoda znače tri različite stvari, a jedan upit ih razlikuje: pokrenite dig za ime prema resolveru koji klijent doista koristi.

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

Vremensko ograničenje izjava je o mreži. NXDOMAIN je izjava o DNS pogledu. Javni odgovor izjava je o politici. Uređivanje zapisa zone dok traje vremensko ograničenje odbacuje jedini koristan dokaz u slučaju.

Zašto adresa plus dva u VPC-u nije udaljeni resolver

Adresa CIDR plus dva lokalna je usluga za resurse unutar VPC-a. AWS dokumentira da prosljeđivanje upita iz lokalnih mreža ili s DNS poslužitelja drugog VPC-a izravno na tu adresu nije podržano i može davati nestabilne rezultate.

To ne znači da eksperiment nikad ne izgleda da radi. Znači da ponašanje nije ugovor koji možete staviti u skriptu podrške. Podržani smjer je dolazna završna točka Resolver: par adresa unutar vašeg VPC-a, dostupan iz mreže koju kontrolirate, koji prihvaća upite koji dolaze izvan AWS-a.

Izgradite put redoslijedom u kojem čisto otkazuje

Moraju postojati tri skoka i svaki ima svoj način otkazivanja.

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

Prosljeđivač treba rutu do adresa završne točke kroz VPN, a povratni put također mora raditi. Za klasični DNS na portu 53 završna točka odgovara preko UDP-a i TCP-a, pa oba protokola moraju biti dopuštena i oba moraju preživjeti svaki nadzor stanja na putu.

Zatim provjerite DNS pogled odvojeno. Privatna hostana zona vidljiva je samo VPC-ovima s kojima je povezana ili kroz namjerni dogovor o dijeljenju. Dostupna završna točka sama po sebi ne čini svaku privatnu zonu razrješivom u njezinu kontekstu razrješavanja.

Odlazna završna točka služi suprotnom smjeru i neće odgovoriti na upit koji dolazi s vašeg prijenosnika.

Provjerite s obje strane

Pitajte s klijenta prema prosljeđivaču, zatim s prosljeđivača prema završnoj točki. Ako klijent otkaže dok prosljeđivač uspije, jaz je između tih dvaju.

Ako oba otkažu, pogledajte sigurnosnu politiku na završnoj točki i izvornu adresu koju doista vidi. Prosljeđivač iza NAT-a predstavlja NAT adresu umjesto VPN adrese prijenosnika i sama ta razlika dovoljna je da upit propadne. Ako oba uspiju, a aplikacija i dalje otkazuje, aplikacija možda koristi drugi resolver od onoga koji ste testirali.

Držite javne i privatne prostore imena namjerno odvojene. Split DNS je politika koju konfigurirate, a ne nuspojava toga da jedan upit slučajno vrati podatke.

Što ne bih učinio

Ne bih dodao NAT pravilo koje je osposobilo jedan upit i to nazvao dizajnom.

Ne bih sve udaljene klijente usmjerio na adresu plus dva samo zato što je jedan test jednom vratio zapis. I ne bih proširio sigurnosnu politiku završne točke na cijeli skup VPN-a kad pristup treba jedan prosljeđivač. Ako organizacija već vodi odobreni prosljeđivač unutar VPC-a, prvo pročitajte taj dizajn, jer druga završna točka koju dodate jest ona koju nitko ne dokumentira.

Povezani članci