AWS Client VPN prieigos taško DNS: kodėl užfiksuotas išspręstas IP neveikia

Praėjusią savaitę dig +short davė vieną adresą jūsų AWS Client VPN profilio prieigos taško pavadinimui, ir tunelis prisijungė. Šią savaitę tas pats profilis jūsų nešiojamajame kompiuteryje stovi ties 'Connecting', o neliestoji kolegos kopija vis dar veikia. Niekas nebuvo užblokuota ir sertifikatas nepasibaigė. Kažkas pakeitė prieigos taško pagrindinio kompiuterio vardą tuo išspręstu adresu, ir paslauga ten nebeatsako. Eksportuotas vardas yra ta dalis, kuri sukurta atlaikyti šį pokytį.

Profilyje esantis vardas gali būti ne tas vardas, kurio klausiama

Iš Client VPN eksportuoti profiliai dažnai turi remote-random-hostname. Įjungus šią parinktį, klientas sukuria vienkartinę žymą, tašku sujungia ją su prieigos taško pavadinimu ir išsprendžia sujungtą vardą. Wildcard įrašas prieigos taško zonoje atsako į bet kurią žymą, todėl išgalvotas priešdėlis vis tiek išsprendžiamas ir todėl šis triukas lieka nematomas, kai bandote rankiniu būdu atkartoti užklausą.

Taigi, kai įklijuojate prieigos taško pavadinimą į terminalą ir gaunate atsakymą, išsprendėte kitą vardą nei tą, kurį klientas naudoja prisijungdamas. Šis neatitikimas nėra defektas, kurį reikėtų taisyti profilyje. Žyma generuojama iš naujo sąmoningai: parinktis neleidžia talpykloms laikyti pasenusio atsakymo, ir ji niekada neatpažįsta jūsų kompiuterio ar sesijos.

Esu susidūręs su suderinamumo atveju, kai klientas parinktį visiškai ignoruoja. AWS dokumentuoja sprendimą: palikite tikrąjį prieigos taško pavadinimą ir pridėkite prieš jį atsitiktinę eilutę bei tašką, traktuodami tai kaip pavadinimų schemą, o ne kaip įklijuojamą reikšmę. Taikyti tai senam klientui pagrįsta; užkoduoti priešdėlį turinčią eilutę kaip prieigos tašką – ne.

Kodėl išsaugotas atsakymas negali likti teisingas

Client VPN prieigos taškų adresus valdo AWS ir jie laikui bėgant keičiasi, ką geriausių praktikų dokumentacija sako tiesiai. Užfiksuotas atsakymas yra vieno sprendimo momentinė kopija. Jį užkoduojantis profilis tampa profiliu, nukreiptu į išimtą iš eksploatacijos kompiuterį, kai tik paslauga persikelia, o gedimas retai atrodo kaip DNS: gaunate prisijungimo laiko limitą arba sustojusį handshake, todėl žmonės vejasi maršrutizavimą ir sertifikatus.

Tas pats atsakymas /etc/hosts paveldi tą pačią galiojimo pabaigą su papildoma problema. hosts įrašas išgyvena perkrovimus, pakartotinius eksportus ir 'įdiekite klientą iš naujo' pataisymus, todėl gedimas grįžta kiekvieną kartą adresui persikėlus. Mačiau, kaip vienas savaitėmis gulėjo nekenksmingas, o paskui išjungė kiekvieną jį turėjusį kompiuterį, kol naujos instaliacijos jungėsi normaliai. Šis suskilimas, viena grupė nepavyksta, o kita tame pačiame account yra tvarkinga, yra pigiausia užuomina, kurią gausite.

Teisingai apibrėžkite atsitiktinumo apimtį. Jis vyksta kiekvienam prisijungimo bandymui. Užmegztas tunelis iš naujo neišsprendžia savo prieigos taško, nekeičia serverių sesijos viduryje, o atskiri programų prašymai nepasirenka kiekvienas naujo VPN kompiuterio. Tik kitas bandymas vėl išsprendžia, todėl visą popietę veikianti sesija nieko nesako apie rytojaus rytą.

Ką paslauga tikrina, kai pakyla tunelis

Client VPN reikalauja, kad adresas, prie kurio esate prisijungę, atitiktų adresą, išspręstą prieigos taško DNS vardui. Šis vienas reikalavimas paaiškina kelis gedimus, atrodančius nesusijusiais: pasirinktinis DNS įrašas, rodantis kitur, pasirinktinis frontend, perduodantis tikruoju prieigos taško adresu, ir profilis, perrašytas į neapdorotą adresą. AWS dokumentuoja pasirinktinio įrašo ir perdavimo derinį kaip gedimą su naujais AWS klientais. Patikra siaura; tai nėra nuosprendis, kad kiekvienas alias draudžiamas.

Tai nėra ir bendra taisyklė apie VPN protokolus. Skaitmeninis remote yra visiškai galiojantis įprastame OpenVPN diegime, ir daugelis taip veikia. Apribojimas kyla iš valdomos sąrangos, o ne iš protokolo po ja.

Todėl sertifikato tikrinimo švelninimas yra neteisingas refleksas. Jei profilis nepavyksta po adreso pakeitimo, serverio tikrinimo išjungimas perkelia klaidą, o ne ištaiso sprendimą ar adreso atitikimo reikalavimą, ir palieka klientą, kuris pasitikės bet kuo. Išsaugokite eksportuotą CA, serverio tikrinimą ir abipusės autentifikacijos nustatymus tiksliai tokius, kokie atėjo.

Leidimų sąrašai, išėjimas ir privatus DNS yra trys atskiros problemos

Ugniasienės taisyklė, kuri turi leisti paskirties vietą prieš nešiojamajam kompiuteriui prisijungiant, susijusi su išoriniu klausytoju. Duokite tinklo savininkui prieigos taško pavadinimą, transportą ir sukonfigūruotą prievadą, tada paklauskite, ar jų kontrolė gali sekti paslaugos DNS elgseną. Taisyklė, laikanti vieną užfiksuotą adresą, yra momentinė kopija su neparašyta galiojimo pabaiga. Jei kontrolė priima tik nekintamas paskirties vietas, išspręskite šią spragą prieš diegimą, o ne tyliai užkoduokite atsakymą.

Partneriui, kuriam reikia fiksuoto šaltinio adreso prašymams po tunelio pakėlimo, galioja kitas reikalavimas: išėjimas. Ką svetainė mato, priklauso nuo programos maršruto ir padalinto tunelio politikos, o ne nuo adreso, prie kurio prisijungė klientas. Padalinto tunelio srautas gali visai nepaliesti AWS.

Privatus DNS tunelio viduje yra trečias sluoksnis. Klientams duotas sprendėjas atsako į vidinius vardus po prisijungimo; jis negali išspręsti viešo prieigos taško, kol tunelio nėra. Prieigos taško sprendimo gedimas ir vidinės programos sprendimo gedimas vyksta skirtinguose etapuose, o jų maišymas nukreipia jus į netinkamą žurnalą.

Adresų šeima priklauso tam pačiam sąrašui. IPv4 atsakymas nieko nesako apie leidžiamą IPv6 ar dvejopo steko prieigos taško kelią, todėl vienoje šeimoje padaryta momentinė kopija nėra įrodymas kitai.

Patikrinkite ryšį nieko neužfiksuodami

Pradėkite nuo profilio tokio, koks buvo eksportuotas, ir perskaitykite, ko jis iš tikrųjų prašo:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Tada palyginkite tris dalykus: profilyje esantį prieigos taško pavadinimą, adresą, kurį klientas praneša naujam bandymui, ir į ką vardas dabar išsprendžiamas. Išsprendžiamas vardas įrodo tik tai, kad įrašas atsako; transportas ir autentifikacija yra atskiri, o prieigos taškas neprivalo atsakyti į ping. Paties kliento žurnalas yra vienintelis vidurinio elemento šaltinis, todėl užfiksuokite jį bandymo metu, o ne po jo.

Šiandien atsakantis adresas yra šiandienos įrodymas; vardas yra tai, ką paslauga palaiko galiojantį. Užrašykite pastebėjimą, nusiųskite jį prieigos taško savininkui ir palikite profilį nukreiptą į vardą.

Dviejų įpročių atsisakykite: sertifikatų patikrų išjungimo, norint pereiti sustojusį handshake, ir žymų krūvos prieš prieigos taško pavadinimą tikintis, kad viena prilips. Žyma išsprendžiama per wildcard įrašą, arba problema yra kitur. Jei teisingai sukonfigūruotas profilis vis tiek nepavyksta, siųskite tikslią užklausą ir prisijungimo įvykį, o ne ilgesnį kompiuterio vardą.

Prieš užverdami: profilis vis dar turi eksportuotą prieigos taško pavadinimą, joks hosts failas nefiksuoja adreso, kliento žurnalo remote atitinka dabartinį sprendimą, o ugniasienės taisyklė įvardija prieigos tašką, o ne adresą. Tai ir būsena, kurią reikia perduoti kitam žmogui.