Prive-DNS wurket yn 'e VPC, mar net oer de VPN
In prive-namme dy't binnen EC2 oplost mar net oer de VPN is in probleem mei it resolverpaad. Lês de flaterfoarm foardat jo de sône-yngong oanpasse.
In prive-namme lost op fan in EC2-ynstânsje, mar net fan in laptop dy't fia de VPN ferbûn is, en de sône sjocht der yn 'e konsole korrekt út. De ympuls is om de yngong oan te passen, wat hast nea it probleem is. De yngong antwurdet immen; hy antwurdet allinnich net jo laptop. Wat tusken de twa oanroppers ferskilt, is hokker resolver se freegje, en oft dy resolver in stipe paad hat nei de DNS-besjoch fan 'e VPC.
Ik begjin mei te bewizen dat de yngong bestiet, en besteegje de rest fan 'e tiid oan it fraachpaad. Dat binne aparte systemen, en se falle op ferskillende manieren.
Lês de flaterfoarm foardat jo eat feroarje
Trije útkomsten betsjutte trije ferskillende dingen, en ien fraach ûnderskiedt se: fieren dig út foar de namme tsjin de resolver dy't de klant eins brûkt.
| 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 |
In tiidferrin is in netwurkferklearring. NXDOMAIN is in DNS-besjochferklearring. In iepenbier antwurd is in beliedsferklearring. In sône-yngong oanpasse wylst jo in tiidferrin hawwe, smyt it iene brûkbere bewiisstik yn 'e saak fuort.
Wêrom't it plus-twa-adres fan 'e VPC gjin ôfstân-resolver is
It CIDR-plus-twa-adres is in lokale tsjinst foar boarnen binnen de VPC. AWS dokumintearret dat it trochstjoeren fan fragen út lokale netwurken, of fan 'e DNS-tsjinners fan in oare VPC, direkt nei dat adres net stipe wurdt en ynstabile resultaten jaan kin.
Dat betsjut net dat in eksperimint nea liket te wurkjen. It betsjut dat it gedrach gjin kontrakt is dat jo yn in helpdesk-skript sette kinne. De stipe rjochting is in ynkommend Resolver-einpunt: in adrespear binnen jo VPC, berikber fan it netwurk dat jo beheare, dat fragen oannimt dy't fan bûten AWS komme.
Bou it paad yn 'e folchoarder dy't skjin falt
Trije sprongen moatte bestean, en elk hat syn eigen manier fan fallen.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesDe trochstjoerder hat in rûte nedich nei de einpuntadressen fia de VPN, en it werompaad moat ek wurkje. Foar konvinsjonele DNS op poarte 53 antwurdet it einpunt oer UDP en TCP, dus beide protokollen moatte tastien wurde en beide moatte elke tastânsyngspeksje yn 'e midden oerlibje.
Kontrolearje dêrnei de DNS-besjoch apart. In prive-hostde sône is allinnich sichtber foar de VPC's dêr't er mei assosjearre is, of fia in bewuste dielregeling. In berikber einpunt makket net op himsels elke prive-sône oplosber yn syn resolúsjekontekst.
In útgeand einpunt tsjinnet de tsjinoerstelde rjochting en sil in fraach dy't fan jo laptop ynkomt net beäntwurdzje.
Ferifiearje fan beide kanten
Freegje fan 'e klant tsjin 'e trochstjoerder, dan fan 'e trochstjoerder tsjin it einpunt. As de klant falt wylst de trochstjoerder slagget, sit de kleau tusken dy twa.
As beide falle, sjoch dan nei it feiligensbelied op it einpunt en nei it boarne-adres dat it eins sjocht. In trochstjoerder efter NAT presintearret it NAT-adres ynstee fan it VPN-adres fan 'e laptop, en dat ferskil allinnich is genôch om de fraach te ferliezen. As beide slagje mar de applikaasje falt noch, brûkt de applikaasje miskien in oare resolver as dy't jo test hawwe.
Hâld de iepenbiere en prive-namme romten mei opsetsin apart. Split DNS is in belied dat jo konfigurearje, gjin by-effekt fan ien opfreger dy't tafallich gegevens weromjout.
Wat ik net dwaan soe
Ik soe gjin NAT-regel tafoegje dy't ien opfreger wurkje liet en dat in ûntwerp neame.
Ik soe net elke ôfstân-klant nei it plus-twa-adres wize om't ien test ien kear in yngong weromjoech. En ik soe it feiligensbelied fan it einpunt net ferbreedzje nei de hiele VPN-pool as ien inkele trochstjoerder tagong nedich hat. As de organisaasje al in goedkarde trochstjoerder binnen de VPC draait, lês dat ûntwerp earst, want it twadde einpunt dat jo tafoegje is dejinge dy't nimmen dokumintearret.