AWS Client VPN-endpunt-DNS: waarom die vaspen van die opgeloste IP misluk

Verlede week het dig +short jou een adres gegee vir die endpuntnaam in jou AWS Client VPN-profiel, en die tonnel het verbind. Hierdie week staan dieselfde profiel op 'Connecting' op jou skootrekenaar terwyl 'n kollega se ongerepte kopie steeds werk. Niks is geblokkeer nie en die sertifikaat het nie verval nie. Iemand het die endpunt-gasheernaam met daardie opgeloste adres vervang, en die diens antwoord nie meer daar nie. Die uitgevoerde naam is die deel wat gebou is om daardie verandering te oorleef.

Die naam in jou profiel is dalk nie die naam wat nagevra word nie

Profiele wat uit Client VPN uitgevoer word, dra dikwels remote-random-hostname. Met daardie opsie aan bou die kliënt 'n weggooi-etiket, voeg dit met 'n punt by die endpuntnaam, en los die saamgestelde naam op. 'n Wildcard-rekord op die endpunt se sone antwoord enige etiket, en daarom los 'n versinde voorvoegsel steeds op en bly die truuk onsigbaar wanneer jy die navraag met die hand probeer herhaal.

Dus, wanneer jy die endpuntnaam in 'n terminaal plak en 'n antwoord kry, het jy 'n ander naam opgelos as die een wat die kliënt by verbindingstyd gebruik. Daardie wanverhouding is nie 'n fout om in die profiel reg te maak nie. Die etiket word doelbewus herskep: die opsie keer dat kasgeheue 'n verouderde antwoord hou, en dit identifiseer nooit jou masjien of jou sessie nie.

Ek het die versoenbaarheidsgeval teëgekom waar 'n kliënt die opsie heeltemal ignoreer. AWS dokumenteer die oplossing: hou die werklike endpuntnaam en voeg 'n ewekansige string plus 'n punt voor, en behandel dit as 'n naamgewingspatroon eerder as 'n waarde om te plak. Om dit op 'n ou kliënt toe te pas is redelik; om die string met voorvoegsel as die endpunt vas te kodeer is nie.

Waarom 'n gestoorde antwoord nie korrek kan bly nie

Client VPN-endpuntadresse word deur AWS bestuur en verander oor tyd, wat die beste-praktyke-dokumentasie duidelik sê. 'n Vastgelê antwoord is 'n momentopname van een oplossing. 'n Profiel wat dit vas kodeer, word 'n profiel gerig op 'n buite bedryf gestelde gasheer sodra die diens skuif, en die mislukking lyk selde na DNS: jy kry 'n verbindingstimeout of 'n stilstaande handskud, so mense jaag roetes en sertifikate na.

Dieselfde antwoord in /etc/hosts erf dieselfde vervaldatum met 'n ekstra probleem daarby. 'n Gasheervoer bly oor herlaai, heruitvoer en 'herstel die kliënt'-regstellings, so die mislukking keer terug elke keer as die adres skuif. Ek het gesien hoe een weke lank onskadelik sit, en dan elke masjien wat dit dra uitskakel terwyl vars installasies normaal verbind. Daardie skeiding, een groep wat faal en 'n ander groep wat reg is op dieselfde rekening, is die goedkoopste leidraad wat jy sal kry.

Bepaal die omvang van die ewekansigmaking ook korrek. Dit gebeur per verbindingspoging. 'n Gevestigde tonnel los nie sy endpunt weer op nie, wissel nie midde-in die sessie van bediener nie, en individuele toepassingsversoeke kies nie elkeen 'n nuwe VPN-gasheer nie. Net die volgende poging los weer op, en daarom sê 'n sessie wat die hele middag werk niks oor môreoggend nie.

Wat die diens nagaan wanneer die tonnel opkom

Client VPN vereis dat die adres waaraan jy verbind is, ooreenstem met 'n adres wat vir die endpunt se DNS-naam opgelos is. Daardie een vereiste verklaar verskeie mislukkings wat onverwant lyk: 'n pasgemaakte DNS-rekord wat elders heen wys, 'n pasgemaakte frontend wat na die werklike endpuntadres aanstuur, en 'n profiel wat na 'n rou adres herskryf is. AWS dokumenteer die pasgemaakte-rekord-plus-aanstuur-reëling as 'n mislukking met onlangse AWS-kliënte. Die kontrole is eng; dit is nie 'n uitspraak dat elke alias verbode is nie.

Dit is ook nie 'n algemene reël oor VPN-protokolle nie. 'n Numeriese remote is heeltemal geldig in 'n gewone OpenVPN-ontplooiing, en baie van hulle werk so. Die beperking kom van die bestuurde reëling, nie van die protokol daaronder nie.

Wat die verslapping van sertifikaatverifikasie die verkeerde refleks maak. As 'n profiel na 'n adresruiling misluk, skuif die uitskakeling van bedienerverifikasie die fout eerder as om die oplossing of die adesooreenstemmingsvereiste reg te maak, en laat 'n kliënt wat enigiets sal vertrou. Hou die uitgevoerde CA, bedienerverifikasie en wedersydse-verifikasie-instellings presies soos hulle gekom het.

Toelatingslyste, uitgang en private DNS is drie aparte probleme

'n Firewall-reël wat 'n bestemming moet toelaat voordat 'n skootrekenaar verbind, gaan oor die buitenste luisteraar. Gee die netwerkeienaar die endpuntnaam, die vervoer en die gekonfigureerde poort, en vra dan of hulle beheer die diens se DNS-gedrag kan volg. 'n Reël wat een vasgevangde adres hou, is 'n momentopname met 'n ongeskrewe vervaldatum. As die beheer net onveranderlike bestemmings aanvaar, besleg daardie gaping voor ontplooiing eerder as om stilweg 'n antwoord vas te kodeer.

'n Vennoot wat 'n vaste bronadres nodig het vir versoeke wat gemaak word nadat die tonnel op is, het 'n ander vereiste: uitgang. Wat 'n webwerf sien, hang af van die toepassingsroete en die split-tonnel-beleid, nie van die adres waaraan die kliënt verbind het nie. Split-getonnelde verkeer mag AWS glad nie raak nie.

Private DNS binne die tonnel is 'n derde laag. Die oplosser wat aan kliënte gegee word, antwoord interne name na verbinding; dit kan nie die publieke endpunt oplos voordat die tonnel bestaan nie. Endpuntoplossingsfaling en interne toepassingsoplossingsfaling gebeur in verskillende stadiums, en om hulle te vermeng stuur jou na die verkeerde log.

Adresfamilie hoort op dieselfde lys. 'n IPv4-antwoord sê niks oor 'n IPv6- of dubbelstapel-endpunt se toegelate pad nie, so 'n momentopname in een familie is nie bewyse vir die ander nie.

Kontroleer 'n verbinding sonder om enigiets vas te pen

Begin by die profiel soos uitgevoer en lees wat dit werklik vra:

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

Vergelyk dan drie dinge: die endpuntnaam wat die profiel hou, die adres wat die kliënt vir 'n vars poging rapporteer, en waarna die naam nou opgelos word. 'n Naam wat oplos, bewys net dat die rekord antwoord; vervoer en verifikasie is apart, en die endpunt hoef nie op 'n ping te antwoord nie. Die kliënt se eie log is die enigste bron vir die middelste item, so vang dit tydens die poging eerder as daarna.

'n Adres wat vandag antwoord, is bewyse oor vandag; die naam is die ding wat die diens geldig hou. Teken die waarneming op, stuur dit na wie ook al die endpunt besit, en laat die profiel na die naam wys.

Twee gewoontes om te laat vaar: sertifikaatkontroles uitskakel om verby 'n stilstaande handskud te kom, en etikette voor die endpuntnaam stapel in die hoop dat een vasslaan. 'n Etiket los op deur die wildcard-rekord of die probleem is elders. As 'n korrek gekonfigureerde profiel steeds misluk, stuur die presiese navraag en die verbindingsgebeurtenis, nie 'n langer gasheernaam nie.

Voordat jy dit afsluit: die profiel dra steeds die uitgevoerde endpuntnaam, geen gasheerlêer pen die adres vas nie, die kliëntlog se remote stem ooreen met 'n huidige oplossing, en die firewall-reël noem die endpunt eerder as 'n adres. Dit is ook die toestand om aan die volgende persoon te gee.