Privata DNS funkcias en la VPC sed ne tra la VPN
Privata nomo, kiu solviĝas en EC2 sed ne tra la VPN, estas problemo de la resolva vojo. Legu la formon de la malsukceso antaŭ ol ŝanĝi la zonan rikordon.
Privata nomo solviĝas el EC2-institucio sed ne el tekkomputilo konektita tra la VPN, kaj la zono aspektas ĝusta en la konzolo. La instinkto estas redakti la rikordon, kio preskaŭ neniam estas la problemo. La rikordo respondas al iu; ĝi simple ne respondas al via tekkomputilo. Kio diferencas inter la du alvokantoj estas kiun resolvilon ili demandas, kaj ĉu tiu resolvilo havas subtenatan vojon en la DNS-vidon de la VPC.
Mi komencas pruvante, ke la rikordo ekzistas, kaj pasigas la reston de la tempo en la demando-vojo. Tiuj estas apartaj sistemoj, kaj ili malsukcesas laŭ diversaj formoj.
Legu la formon de la malsukceso antaŭ ol ŝanĝi ion ajn
Tri rezultoj signifas tri diversajn aferojn, kaj unu demando distingas ilin: rulu dig por la nomo kontraŭ la resolvilo, kiun la kliento fakte uzas.
| 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 |
Tempa limo estas aserto pri la reto. NXDOMAIN estas aserto pri la DNS-vido. Publika respondo estas aserto pri la politiko. Redakti zonan rikordon dum ekzistas tempa limo forĵetas la solan utilan pruvon de la kazo.
Kial la plus-du adreso de la VPC ne estas fora resolvilo
La CIDR-plus-du adreso estas loka servo por rimedoj ene de la VPC. AWS dokumentas, ke plusendado de demandoj el lokaj retoj, aŭ el la DNS-serviloj de alia VPC, rekte al tiu adreso ne estas subtenata kaj povas doni malstabilajn rezultojn.
Tio ne signifas, ke eksperimento neniam ŝajnas funkcii. Ĝi signifas, ke la konduto ne estas kontrakto, kiun vi povas meti en subtenan skripton. La subtenata direkto estas envena Resolver-finpunkto: adresparo ene de via VPC, atingebla el la reto, kiun vi kontrolas, kiu akceptas demandojn venantajn de ekster AWS.
Konstruu la vojon laŭ la ordo, en kiu ĝi malsukcesas pure
Devas ekzisti tri saltoj, kaj ĉiu havas sian propran manieron malsukcesi.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesLa plusendilo bezonas vojon al la finpunktaj adresoj tra la VPN, kaj la revena vojo ankaŭ devas funkcii. Por konvencia DNS sur pordo 53 la finpunkto respondas per UDP kaj TCP, do ambaŭ protokoloj devas esti permesitaj kaj ambaŭ devas transvivi ajnan statan inspektadon meze.
Poste kontrolu la DNS-vidon aparte. Privata gastigata zono estas videbla nur por la VPC-oj, kun kiuj ĝi estas asociita, aŭ per intenca kunhava interkonsento. Atingebla finpunkto ne mem igas ĉiun privatan zonon solvebla en sia solvokunteksto.
Elvena finpunkto servas la kontraŭan direkton kaj ne respondos demandon venantan de via tekkomputilo.
Kontrolu de ambaŭ finoj
Demandu de la kliento kontraŭ la plusendilo, poste de la plusendilo kontraŭ la finpunkto. Se la kliento malsukcesas dum la plusendilo sukcesas, la breĉo estas inter tiuj du.
Se ambaŭ malsukcesas, rigardu la sekurecan politikon sur la finpunkto kaj la fontadreson, kiun ĝi fakte vidas. Plusendilo malantaŭ NAT prezentas la NAT-adreson anstataŭ la VPN-adreso de la tekkomputilo, kaj tiu diferenco sole sufiĉas por forlasi la demandon. Se ambaŭ sukcesas sed la aplikaĵo ankoraŭ malsukcesas, eble la aplikaĵo uzas alian resolvilon ol tiun, kiun vi testis.
Tenu la publikajn kaj privatajn nomspacojn aparte intence. Split DNS estas politiko, kiun vi agordas, ne flanka efiko de unu serĉo hazarde redonanta datumojn.
Kion mi ne farus
Mi ne aldonus NAT-regulon, kiu igis unu serĉon funkcii, kaj nomus tion dezajno.
Mi ne direktus ĉiun foran klienton al la plus-du adreso ĉar unu testo iam redonis rikordon. Kaj mi ne vastigus la sekurecan politikon de la finpunkto al la tuta VPN-pool, kiam unu sola plusendilo bezonas aliron. Se la organizo jam funkciigas aprobitan plusendilon ene de la VPC, legu tiun dezajnon unue, ĉar la dua finpunkto, kiun vi aldonas, estas tiu, kiun neniu dokumentas.