Privatno ime razrješava se s EC2 instance, ali ne s laptopa spojenog preko VPN-a, a zona u konzoli izgleda ispravno. Prvi nagon je urediti zapis, što skoro nikada nije problem. Zapis odgovara nekome; jednostavno ne odgovara vašem laptopu. Ono što se razlikuje između dva pozivaoca jeste koji resolver pitaju i ima li taj resolver podržanu putanju u DNS prikaz unutar VPC-a.

Počinjem tako što dokažem da zapis postoji, a ostatak vremena provodim na putanji upita. To su odvojeni sistemi i otkazuju na različite načine.

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

Tri ishoda znače tri različite stvari, a jedan upit ih razlikuje: pokrenite dig za ime prema resolveru koji klijent zaista 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 je izjava o mreži. NXDOMAIN je izjava o DNS prikazu. Javni odgovor je izjava 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 je lokalna usluga za resurse unutar VPC-a. AWS dokumentuje da prosljeđivanje upita iz lokalnih mreža, ili s DNS servera drugog VPC-a, direktno na tu adresu nije podržano i može davati nestabilne rezultate.

To ne znači da eksperiment nikada ne izgleda da radi. Znači da ponašanje nije ugovor koji možete staviti u skriptu podrške. Podržani smjer je dolazni Resolver endpoint: par adresa unutar vašeg VPC-a, dostupan iz mreže koju kontrolišete, koji prihvata upite koji dolaze izvan AWS-a.

Izgradite putanju redoslijedom u kojem čisto otkazuje

Moraju postojati tri skoka, a 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 endpointa kroz VPN, a povratna putanja također mora raditi. Za klasični DNS na portu 53 endpoint odgovara preko UDP-a i TCP-a, pa oba protokola moraju biti dozvoljena i oba moraju preživjeti svaki nadzor stanja na putu.

Zatim provjerite DNS prikaz odvojeno. Privatna hostovana zona vidljiva je samo VPC-ovima s kojima je povezana, ili kroz namjerni dogovor o dijeljenju. Dostupan endpoint sam po sebi ne čini svaku privatnu zonu razrješivom u njenom kontekstu razrješavanja.

Odlazni endpoint služi suprotnom smjeru i neće odgovoriti na upit koji dolazi s vašeg laptopa.

Provjerite s oba kraja

Pitajte s klijenta prema prosljeđivaču, zatim s prosljeđivača prema endpointu. Ako klijent otkaže dok prosljeđivač uspije, razmak je između tih dvaju.

Ako oba otkažu, pogledajte sigurnosnu politiku na endpointu i izvornu adresu koju zaista vidi. Prosljeđivač iza NAT-a predstavlja NAT adresu umjesto VPN adrese laptopa, a sama ta razlika dovoljna je da upit propadne. Ako oba uspiju, ali aplikacija i dalje otkazuje, moguće je da aplikacija koristi drugi resolver od onoga koji ste testirali.

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

Šta ne bih uradio

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 endpointa na cijeli VPN bazen kad pristup treba jedan prosljeđivač. Ako organizacija već vodi odobreni prosljeđivač unutar VPC-a, prvo pročitajte taj dizajn, jer je druga endpoint adresa koju dodate ona koju niko ne dokumentuje.

Povezani članci