Privatno ime se razrešava sa EC2 instance, ali ne sa laptopa povezanog 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.

Krećem od dokazivanja 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 pre nego što bilo šta promenite

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 prosleđivanje upita iz lokalnih mreža, ili sa 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 smer 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 redosledom 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

Prosleđivač treba rutu do adresa endpointa kroz VPN, a povratna putanja takođe 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živeti svaki nadzor stanja na putu.

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

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

Proverite sa oba kraja

Pitajte sa klijenta prema prosleđivaču, zatim sa prosleđivača prema endpointu. Ako klijent otkaže dok prosleđivač uspe, razmak je između tih dvaju.

Ako oba otkažu, pogledajte sigurnosnu politiku na endpointu i izvornu adresu koju zaista vidi. Prosleđivač iza NAT-a predstavlja NAT adresu umesto VPN adrese laptopa, a sama ta razlika dovoljna je da upit propadne. Ako oba uspeju, 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 namerno 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 usmerio na adresu plus dva samo zato što je jedan test jednom vratio zapis. I ne bih proširio sigurnosnu politiku endpointa na ceo VPN bazen kad pristup treba jedan prosleđivač. Ako organizacija već vodi odobreni prosleđivač unutar VPC-a, prvo pročitajte taj dizajn, jer je druga endpoint adresa koju dodate ona koju niko ne dokumentuje.

Povezani članci