Gumagana ang pribadong DNS sa VPC pero hindi sa VPN
Ang pribadong pangalan na nare-resolve sa EC2 pero hindi sa VPN ay problema sa ruta ng resolver. Basahin ang hugis ng pagpalya bago i-edit ang tala ng zone.
Nare-resolve ang pribadong pangalan mula sa EC2 instance pero hindi mula sa laptop na konektado sa VPN, at mukhang tama ang zone sa console. Ang unang reaksiyon ay i-edit ang tala, na halos hindi kailanman ang problema. Sumasagot ang tala sa isang tao; hindi lang ito sumasagot sa laptop mo. Ang pagkakaiba ng dalawang tumatawag ay kung aling resolver ang tinatanong nila at kung may sinusuportahang ruta ang resolver na iyon papunta sa DNS view ng VPC.
Nagsisimula ako sa pagpapatunay na umiiral ang tala, pagkatapos ginugugol ang natitirang oras sa ruta ng query. Magkaibang sistema ang mga ito at nagpalya sa magkaibang hugis.
Basahin ang hugis ng pagpalya bago baguhin ang anuman
Tatlong resulta ang ibig sabihin ng tatlong magkaibang bagay, at isang query ang naghihiwalay sa kanila: patakbuhin ang dig para sa pangalan laban sa resolver na aktwal na ginagamit ng kliyente.
| 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 |
Ang timeout ay pahayag tungkol sa network. Ang NXDOMAIN ay pahayag tungkol sa DNS view. Ang pampublikong sagot ay pahayag tungkol sa patakaran. Ang pag-edit ng tala ng zone habang may timeout ay nagtatapon ng nag-iisang kapaki-pakinabang na ebidensya sa kaso.
Bakit ang plus-dalawang address ng VPC ay hindi remote resolver
Ang CIDR plus-dalawang address ay lokal na serbisyo para sa mga resource sa loob ng VPC. Idinodokumento ng AWS na ang pagpapasa ng query mula sa on-premises na network, o mula sa DNS server ng ibang VPC, nang direkta sa address na iyon ay hindi sinusuportahan at maaaring magbigay ng hindi matatag na resulta.
Hindi ibig sabihin nito na ang eksperimento ay hindi kailanman mukhang gumagana. Ibig sabihin, ang pag-uugali ay hindi kontratang maaaring ilagay sa script ng helpdesk. Ang sinusuportahang direksyon ay inbound Resolver endpoint: isang pares ng address sa loob ng VPC mo, na maabot mula sa network na kontrolado mo, na tumatanggap ng query na dumarating mula sa labas ng AWS.
Buuin ang ruta sa pagkakasunod-sunod kung saan malinis itong nagpalya
Dapat may tatlong hop, at bawat isa ay may sariling paraan ng pagpalya.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesKailangan ng forwarder ng ruta patungo sa mga address ng endpoint sa pamamagitan ng VPN, at dapat gumana rin ang pabalik na ruta. Para sa karaniwang DNS sa port 53, sumasagot ang endpoint sa UDP at TCP, kaya dapat payagan ang dalawang protocol at dapat lumampas ang dalawa sa anumang stateful inspection sa gitna.
Pagkatapos, suriin ang DNS view nang hiwalay. Ang pribadong hosted zone ay nakikita lamang ng mga VPC na konektado rito, o sa pamamagitan ng sadyang kaayusan sa pagbabahagi. Ang naaabot na endpoint ay hindi nagpapataas ng lahat ng pribadong zone na maging resolve-able sa konteksto ng resolution nito.
Ang outbound endpoint ay nagsisilbi sa kabaligtarang direksyon at hindi sasagot sa query na papasok mula sa laptop mo.
I-verify mula sa dalawang dulo
Mag-query mula sa kliyente laban sa forwarder, pagkatapos mula sa forwarder laban sa endpoint. Kung nagpalya ang kliyente habang nagtagumpay ang forwarder, nasa pagitan ng dalawang iyon ang agwat.
Kung parehong nagpalya, tingnan ang patakaran sa seguridad sa endpoint at ang source address na aktwal nitong nakikita. Ang forwarder sa likod ng NAT ay nagpapakita ng NAT address sa halip na VPN address ng laptop, at ang pagkakaibang iyon lamang ay sapat na para i-drop ang query. Kung parehong nagtagumpay pero nagpalya pa rin ang aplikasyon, maaaring gumagamit ang aplikasyon ng ibang resolver kaysa sa sinubukan mo.
Panatilihing hiwalay ang pampubliko at pribadong namespace nang sadya. Ang Split DNS ay patakarang kinokonfigura mo, hindi side effect ng isang lookup na nagkataong nagbalik ng data.
Ang hindi ko gagawin
Hindi ako magdadagdag ng NAT rule na nagpagana ng isang lookup at tatawagin itong disenyo.
Hindi ko ituturo ang lahat ng remote client sa plus-dalawang address dahil isang beses nagbalik ng tala ang isang test. At hindi ko palalawakin ang patakaran sa seguridad ng endpoint sa buong VPN pool kapag isang forwarder lang ang kailangan ng access. Kung may tumatakbong aprubadong forwarder ang organisasyon sa loob ng VPC, basahin muna ang disenyong iyon, dahil ang idadagdag mong pangalawang endpoint ang siyang walang nagdodokumento.