DNS í AWS Client VPN: notaðu resolver VPC, ekki subnetið

Endapunkturinn er í 10.0.8.0/24, svo resolverinn verður að vera 10.0.8.2. Þetta er röksemdin sem ég heyri oftast og hún er röng tvisvar. Route 53 Resolver svarar á aðal IPv4 sviði VPC plús tveir, sem fyrir VPC 10.0.0.0/16 er 10.0.0.2, sama hvaða subnet endapunkturinn notar. Seinna mistakið er hljóðlátara: að setja rétta vistfangið í endapunktinn þýðir ekki að stýrikerfi biðlarans spyrji það nokkurn tíma um neitt. Bæði mistökin gefa sama einkenni: nafnaleysing virkar hjá sumum biðlurum og mistekst hjá öðrum.

Goðsögnin byrjar á subnet tengingunni

Tengingin snýst um hvar teygjanlegu netviðmótin fyrir biðlara eru, ekki um hvaða resolver vistfang er til. Subnet endapunktsins gefa biðlurum vistfang inni í VPC, og ekkert þeirra ber sinn eigin resolver.

Þegar þú aðgreinir þessar tvær hugmyndir hættir reikningurinn að vera ráðgáta og bilanaleitin færist yfir á biðlarann, þar sem flest þessara mála enda í raun.

Reiknaðu vistfangið út frá aðalsviði VPC

Taktu aðal IPv4 CIDR VPC og bættu tveimur við netfangið. 10.0.0.0/16 gefur 10.0.0.2, 172.31.0.0/16 gefur 172.31.0.2, og VPC með aukasvið heldur resolvernum á aðalsviðinu. Subnet 10.0.8.0/24 inni í því VPC færir hann ekki. Skrifaðu vistfangið við hlið VPC ID áður en þú snertir endapunktinn, því talan er eiginleiki VPC og ekki tengingarinnar.

VPC svarar líka á link-local vistfanginu 169.254.169.253. Það vistfang er aðgengilegt innan VPC, en það er ekki almenn bein leið fyrir fartölvu hinum megin við göng.

Þannig eru tvö gild resolver vistföng, og hvort tveggja er ekki subnet plús tveir.

Hvað stilling endapunktsins gerir og hvað ekki

Client VPN endapunkturinn hefur DNS netþjónsreiti, og þar sem stjórnborðið býður VPC resolver val fyllir það sama hugmyndina. Að stilla þá breytir því sem þjónustan afhendir biðlurum við tengingu. Það breytir ekki því sem óstýrður OpenVPN biðlari gerir með gildið, því biðlarinn verður enn að beita því á stýrikerfið. Úr þessu gloppi kemur „virkar á Macinum mínum en ekki á Linux vélinni“.

Á Linux á tengistjórinn resolver samþættinguna frekar en notandinn. Að breyta /etc/resolv.conf handvirkt sannar að vistfangið virkar fyrir eina lotu og hverfur svo við endurtengingu — þess vegna koma svo mörg löguð mál aftur næsta morgun.

Athugaðu virka resolverinn á biðlaranum eftir tengingu, ekki stillingasíðu endapunktsins.

Split tunneling getur sigrað réttan resolver

Með split tunneling eru aðeins leiðir sem ýtt er inn í göngin notaðar. Ef resolver vistfangið er ekki á leið fer fyrirspurnin út um staðbundna viðmótið og heimanetbeinin svarar. Vistfangið í endapunktinum er enn rétt og uppflettingin mistekst enn. Bættu leiðinni fyrir resolverinn við og prófaðu aftur.

Skörun staðbundinna sviða gefur sömu niðurstöðu á óþægilegri hátt: fyrirspurninni er svarað, bara af röngum netþjóni.

Ekki opna öryggishópa fyrir Amazon DNS vistfangið

Eðlishvötin þegar uppflettingar tímoutast er að bæta við reglu sem leyfir UDP 53 á resolver vistfangið. AWS skjalfestir að öryggishópar og net-ACL sía ekki Amazon DNS umferð eins og þau sía umferð til eigin DNS eintaks. Að opna þessar reglur breytir engu fyrir VPC resolverinn og víkkar mörkin án ástæðu. Resolver sem þú rekur sjálf er annað mál og þarf sannarlega eigin reglur.

Ef bæði koma fyrir í hönnuninni skaltu athuga við hvort biðlarinn stefnir í raun áður en þú breytir einhverri reglu.

Staðfestu slóðina og mældu svo eitthvað annað

Leystu opinbert nafn, leystu einkanaffn skráð í einkahýst svæði sem tengist VPC, og lestu virka resolver biðlarans þar á milli. Sú röð aðgreinir „resolver vistfangið er rangt“ frá „svæðið er ekki tengt“ og frá „biðlarinn hunsaði stillinguna“. Hvert hefur aðra lagfæringu og ekkert þeirra er afkastavandamál.

Árangursrík uppfletting segir ekkert um viðvarandi flutningshraða, svo haltu þessum tveimur samtölum aðskildum þegar þú skýrslar.