DNS-ul privat funcționează în VPC, dar nu prin VPN
Un nume privat care se rezolvă în EC2 dar nu prin VPN este o problemă de traseu al resolverului. Citește forma defecțiunii înainte de a edita înregistrarea zonei.
Un nume privat se rezolvă de pe o instanță EC2, dar nu de pe un laptop conectat prin VPN, iar zona arată corect în consolă. Instinctul este să editezi înregistrarea, ceea ce aproape niciodată nu este problema. Înregistrarea răspunde cuiva; pur și simplu nu răspunde laptopului tău. Ce diferă între cei doi apelanți este ce resolver întreabă și dacă acel resolver are o cale acceptată către vizualizarea DNS a VPC-ului.
Încep prin a demonstra că înregistrarea există, apoi petrec restul timpului pe traseul interogării. Sunt sisteme separate și eșuează în moduri diferite.
Citește forma defecțiunii înainte de a schimba ceva
Trei rezultate înseamnă trei lucruri diferite, iar o singură interogare le distinge: rulează dig pentru nume împotriva resolverului pe care clientul îl folosește efectiv.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Un timeout este o afirmație despre rețea. NXDOMAIN este o afirmație despre vizualizarea DNS. Un răspuns public este o afirmație despre politică. Dacă editezi o înregistrare de zonă cât timp există un timeout, arunci singura dovadă utilă din caz.
De ce adresa plus doi a VPC-ului nu este un resolver la distanță
Adresa CIDR plus doi este un serviciu local pentru resursele din interiorul VPC-ului. AWS documentează că redirecționarea interogărilor din rețele locale, sau de la serverele DNS ale altui VPC, direct către acea adresă nu este acceptată și poate produce rezultate instabile.
Asta nu înseamnă că un experiment nu pare niciodată să funcționeze. Înseamnă că comportamentul nu este un contract pe care îl poți pune într-un script de suport. Direcția acceptată este un endpoint Resolver de intrare: o pereche de adrese în VPC-ul tău, accesibilă din rețeaua pe care o controlezi, care acceptă interogări venite din afara AWS.
Construiește traseul în ordinea în care eșuează curat
Trebuie să existe trei salturi, iar fiecare are propriul mod de a eșua.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesForwarderul are nevoie de o rută către adresele endpointului prin VPN, iar calea de întoarcere trebuie și ea să funcționeze. Pentru DNS convențional pe portul 53, endpointul răspunde prin UDP și TCP, deci ambele protocoale trebuie permise și ambele trebuie să supraviețuiască oricărei inspecții cu stare pe parcurs.
Apoi verifică separat vizualizarea DNS. O zonă găzduită privată este vizibilă doar pentru VPC-urile cu care este asociată, sau printr-un acord de partajare deliberat. Un endpoint accesibil nu face, prin el însuși, ca fiecare zonă privată să fie rezolvabilă în contextul său de rezoluție.
Un endpoint de ieșire servește direcția opusă și nu va răspunde la o interogare care vine de pe laptopul tău.
Verifică de la ambele capete
Interoghează de la client către forwarder, apoi de la forwarder către endpoint. Dacă clientul eșuează în timp ce forwarderul reușește, diferența este între acele două.
Dacă ambele eșuează, uită-te la politica de securitate a endpointului și la adresa sursă pe care o vede efectiv. Un forwarder din spatele NAT prezintă adresa NAT în locul adresei VPN a laptopului, iar această diferență singură este suficientă pentru a elimina interogarea. Dacă ambele reușesc dar aplicația tot eșuează, este posibil ca aplicația să folosească un alt resolver decât cel pe care l-ai testat.
Ține separate intenționat spațiile de nume publice și private. Split DNS este o politică pe care o configurezi, nu un efect secundar al faptului că o singură căutare returnează date din întâmplare.
Ce nu aș face
Nu aș adăuga o regulă NAT care a făcut o singură căutare să funcționeze și aș numi asta proiect.
Nu aș îndrepta fiecare client la distanță către adresa plus doi pentru că un test a returnat o înregistrare o dată. Și nu aș lărgi politica de securitate a endpointului la tot pool-ul VPN când un singur forwarder are nevoie de acces. Dacă organizația rulează deja un forwarder aprobat în interiorul VPC-ului, citește mai întâi acel proiect, pentru că al doilea endpoint pe care îl adaugi este cel pe care nimeni nu îl documentează.