DNS de AWS Client VPN-finpunkto: kial fiksi la solvitan IP malsukcesas

Pasintan semajnon dig +short donis al vi unu adreson por la finpunkta nomo en via AWS Client VPN-profilo, kaj la tunelo konektiĝis. Ĉi-semajne la sama profilo restas ĉe 'Connecting' sur via tekkomputilo dum la netuŝita kopio de kolego ankoraŭ funkcias. Nenio estis blokita kaj la atestilo ne eksvalidiĝis. Iu anstataŭigis la gastigan nomon de la finpunkto per tiu solvita adreso, kaj la servo ne plu respondas tie. La elportita nomo estas la parto konstruita por postvivi tiun ŝanĝon.

La nomo en via profilo eble ne estas la nomo petata

Profiloj elportitaj el Client VPN kutime portas remote-random-hostname. Kun tiu opcio aktiva, la kliento konstruas unufojan etikedon, kunigas ĝin al la finpunkta nomo per punkto kaj solvas la kunmetitan nomon. Ĵokera registro en la zono de la finpunkto respondas al iu ajn etikedo, tial elpensita prefikso ankoraŭ solviĝas kaj tial la artifiko restas nevidebla kiam vi provas reprodukti la peton permane.

Do kiam vi algluas la finpunktan nomon en terminalon kaj ricevas respondon, vi solvis alian nomon ol tiu, kiun la kliento uzas dum konekto. Tiu malkongruo ne estas difekto por korekti en la profilo. La etikedo estas regenerata intence: la opcio malhelpas kaŝmemorojn teni malnovan respondon, kaj ĝi neniam identigas vian maŝinon aŭ vian seancon.

Mi renkontis la kongruan kazon kie kliento tute ignoras la opcion. AWS dokumentas la solvon: konservu la veran finpunktan nomon kaj antaŭmetu hazardan ĉenon plus punkton, traktante ĝin kiel nomigan ŝablonon anstataŭ kiel algluendan valoron. Apliki tion al malnova kliento estas racia; firmigi la prefiksan ĉenon kiel la finpunkto ne estas.

Kial konservita respondo ne povas resti ĝusta

Client VPN-finpunktaj adresoj estas administrataj de AWS kaj ŝanĝiĝas laŭ la tempo, kion la dokumentaro pri bonaj praktikoj diras rekte. Kaptita respondo estas momenta bildo de unu solvo. Profilo, kiu firmigas ĝin, fariĝas profilo celanta malmuntitan gastiganton tuj kiam la servo translokiĝas, kaj la fiasko malofte aspektas kiel DNS: vi ricevas konektan tempolimon aŭ haltintan manpremon, do homoj ĉasasvojajn kaj atestilojn.

La sama respondo en /etc/hosts heredas la saman eksvalidiĝon kun plia problemo. hosts-afiŝo postvivas restartojn, reajn eksportojn kaj 'reinstalu la klienton'-riparojn, do la fiasko revenas ĉiufoje kiam la adreso translokiĝas. Mi vidis unu kuŝi sendanĝere dum semajnoj, poste elfaligi ĉiun maŝinon portantan ĝin dum freŝaj instalaĵoj konektiĝis normale. Tiu disiĝo, unu grupo fiaskanta kaj alia bona en la sama konto, estas la plej malmultekosta spuro, kiun vi ricevos.

Limigu la hazardigon ĝuste. Ĝi okazas por ĉiu konekta provo. Starigita tunelo ne re-solvas sian finpunkton, ne ŝanĝas servilojn meze de seanco, kaj individuaj aplikaĵpetoj ne elektas ĉiu novan VPN-gastiganton. Nur la sekva provo solvas denove, tial seanco funkcianta la tutan posttagmezon diras nenion pri morgaŭ matene.

Kion la servo kontrolas kiam la tunelo ekfunkcias

Client VPN postulas ke la adreso, al kiu vi estas konektita, kongruu kun adreso solvita por la DNS-nomo de la finpunkto. Tiu unu postulo klarigas plurajn fiaskojn, kiuj ŝajnas nerilataj: propra DNS-registro montranta aliloken, propra frontend plusendanta al la vera finpunkta adreso, kaj profilo reskribita al kruda adreso. AWS dokumentas la aranĝon de propra registro plus plusendado kiel fiaskon kun lastatempaj AWS-klientoj. La kontrolo estas mallarĝa; ĝi ne estas verdikto, ke ĉiu alinomo estas malpermesita.

Ĝi ankaŭ ne estas ĝenerala regulo pri VPN-protokoloj. Numera remote estas tute valida en ordinara OpenVPN-ekspluo, kaj multaj funkcias tiel. La limigo venas de la administrata aranĝo, ne de la protokolo sub ĝi.

Kio faras malstreĉigon de atestila kontrolo la malĝustan reflekson. Se profilo fiaskas post adresa ŝanĝo, malŝalti la servilan kontrolon movas la eraron anstataŭ ripari la solvon aŭ la postulon pri adresa kongruo, kaj lasas klienton, kiu fidos ion ajn. Konservu la elportitan CA, servilan kontrolon kaj agordojn de reciproka aŭtentigo ĝuste kiel ili venis.

Permeslistoj, eliro kaj privata DNS estas tri apartaj problemoj

Fajroŝirma regulo, kiu devas permesi celon antaŭ ol tekkomputilo konektiĝas, temas pri la ekstera aŭskultanto. Donu al la retposedanto la finpunktan nomon, la transporton kaj la agorditan pordon, poste demandu ĉu ilia kontrolo povas sekvi la DNS-konduton de la servo. Regulo tenanta unu kaptitan adreson estas momenta bildo kun neskribita eksvalidiĝo. Se la kontrolo akceptas nur senŝanĝajn celojn, solvu tiun breĉon antaŭ la lanĉo anstataŭ silente firmigi respondon.

Partnero, kiu bezonas fiksan fontan adreson por petoj faritaj post kiam la tunelo staras, havas alian postulon: eliron. Kion retejo observas dependas de la aplika vojo kaj la politiko de dividita tunelo, ne de la adreso al kiu la kliento konektiĝis. Trafiko de dividita tunelo eble tute ne tuŝas AWS.

Privata DNS ene de la tunelo estas tria tavolo. La solvilo donita al klientoj respondas internajn nomojn post konekto; ĝi ne povas solvi la publikan finpunkton antaŭ ol la tunelo ekzistas. Fiasko de finpunkta solvo kaj fiasko de interna aplika solvo okazas en malsamaj etapoj, kaj miksado sendas vin al la malĝusta protokolo.

Adresa familio apartenas al la sama listo. IPv4-respondo diras nenion pri la permesita vojo de IPv6 aŭ duobla staka finpunkto, do momenta bildo prenita en unu familio ne estas pruvo por la alia.

Kontrolu konekton sen fiksi ion ajn

Komencu de la profilo kiel elportite kaj legu, kion ĝi vere petas:

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

Poste komparu tri aferojn: la finpunktan nomon tenatan de la profilo, la adreson raportitan de la kliento por freŝa provo, kaj al kio la nomo solviĝas nun. Nomo, kiu solviĝas, pruvas nur ke la registro respondas; transporto kaj aŭtentigo estas apartaj, kaj la finpunkto ne devas respondi al ping. La propra protokolo de la kliento estas la sola fonto por la meza ero, do kaptu ĝin dum la provo, ne poste.

Adreso, kiu respondas hodiaŭ, estas pruvo pri hodiaŭ; la nomo estas tio, kion la servo tenas valida. Notu la observon, sendu ĝin al tiu, kiu posedas la finpunkton, kaj lasu la profilon montri al la nomo.

Du kutimojn forlasi: malŝalti atestilajn kontrolojn por preteriri haltintan manpremon, kaj staki etikedojn antaŭ la finpunkta nomo esperante ke unu gluiĝos. Etikedo solviĝas per la ĵokera registro aŭ la problemo estas aliloke. Se ĝuste agordita profilo ankoraŭ fiaskas, sendu la precizan peton kaj la konektan eventon, ne pli longan gastigantan nomon.

Antaŭ ol fermi: la profilo ankoraŭ portas la elportitan finpunktan nomon, neniu hosts-dosiero fiksas la adreson, la remote en la klienta protokolo kongruas kun nuna solvo, kaj la fajroŝirma regulo nomas la finpunkton anstataŭ adreson. Tio ankaŭ estas la stato por transdoni al la sekva persono.