Einkadns virkar í VPC en ekki í gegnum VPN

Einkheiti leysist frá EC2-tilviki en ekki frá fartölvu sem er tengd í gegnum VPN, og svæðið lítur rétt út í stjórnborðinu. Fyrsta hvatningin er að breyta færslunni, sem er næstum aldrei vandamálið. Færslan svarar einhverjum; hún svarar bara ekki fartölvunni þinni. Það sem greinir hina tvo kallendur er hvaða resolver þeir spyrja og hvort sá resolver hafi studda leið inn í DNS-sýn VPC.

Ég byrja á að sanna að færslan sé til og eyði restinni af tímanum í fyrirspurnarleiðina. Þetta eru aðskilin kerfi og þau bila á mismunandi hátt.

Lestu form bilunarinnar áður en þú breytir einhverju

Þrjár niðurstöður þýða þrjá mismunandi hluti og ein fyrirspurn greinir þá: keyrðu dig fyrir heitið á móti þeim resolver sem biðlarinn notar í raun.

Tímamörk eru fullyrðing um netið. NXDOMAIN er fullyrðing um DNS-sýnina. Opinbert svar er fullyrðing um stefnuna. Að breyta svæðisfærslu á meðan tímamörk eru fyrir hendi hendir frá sér eina gagnlega sönnunargagninu í málinu.

Hvers vegna plús-tveggja vistfang VPC er ekki fjarlægur resolver

CIDR plús-tveggja vistfangið er staðbundin þjónusta fyrir auðlindir inni í VPC. AWS skjalfestir að framsending fyrirspurna frá staðbundnum netum, eða frá DNS-þjónum annars VPC, beint á þetta vistfang sé ekki studd og geti gefið óstöðugar niðurstöður.

Það þýðir ekki að tilraun virðist aldrei virka. Það þýðir að hegðunin er ekki samningur sem þú getur sett í hjálparskrift. Studda áttin er innkominn Resolver-endapunktur: vistfangapars inni í VPC-inu þínu, aðgengilegt frá netinu sem þú stýrir og tekur við fyrirspurnum sem koma frá utan AWS.

Byggðu leiðina í þeirri röð sem hún bilar hreint

Þrjú hopp verða að vera til og hvert hefur sinn hátt til að bila.

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

Framsendandinn þarf leið að vistföngum endapunktsins í gegnum VPN og bakleiðin verður líka að virka. Fyrir hefðbundið DNS á porti 53 svarar endapunkturinn um UDP og TCP, svo báðar sáttmálarnar verða að vera leyfðar og báðar verða að lifa af hvers kyns stöðuskoðun í miðjunni.

Athugaðu síðan DNS-sýnina sérstaklega. Einkahýst svæði er aðeins sýnilegt VPC-unum sem það er tengt, eða í gegnum viljandi samnýtingarfyrirkomulag. Aðgengilegur endapunktur gerir ekki eitt og sér hvert einkasvæði leysanlegt í sínum leysingarsamhengi.

Útfarandi endapunktur þjónar gagnstæðri átt og svarar ekki fyrirspurn sem kemur frá fartölvunni þinni.

Staðfestu frá báðum endum

Spyrðu frá biðlaranum á móti framsendandanum og síðan frá framsendandanum á móti endapunktinum. Ef biðlarinn bilar á meðan framsendandinn tekst, er bilið á milli þeirra tveggja.

Ef báðir bila, skoðaðu öryggisstefnuna á endapunktinum og upprunavistfangið sem hann sér í raun. Framsendandi bakvið NAT sýnir NAT-vistfangið í stað VPN-vistfangs fartölvunnar, og sá munur einn er nóg til að fella fyrirspurnina. Ef báðir takast en forritið bilar samt, gæti forritið verið að nota annan resolver en þann sem þú prófaðir.

Haltu opinberu og einkarekinunum viljandi aðskildum. Split DNS er stefna sem þú stillir, ekki aukaverkun af einni leit sem skyldi skila gögnum.

Það sem ég myndi ekki gera

Ég myndi ekki bæta við NAT-reglu sem lét eina leit virka og kalla það hönnun.

Ég myndi ekki beina hverjum fjarlægum biðlara á plús-tveggja vistfangið bara af því að ein prófun skilaði einu sinni færslu. Og ég myndi ekki víkka öryggisstefnu endapunktsins út í allt VPN-laugina þegar einn framsendandi þarf aðgang. Ef stofnunin rekur þegar samþykktan framsendanda inni í VPC, lestu þá hönnun fyrst, því annar endapunkturinn sem þú bætir við er sá sem enginn skjalfestir.