AWS Client VPN -päätepisteen DNS: miksi ratkaistun IP:n kiinnittäminen epäonnistuu

Viime viikolla dig +short antoi yhden osoitteen AWS Client VPN -profiilisi päätepisteen nimelle, ja tunneli yhdistyi. Tällä viikolla sama profiili jää kannettavassasi tilaan 'Connecting', kun kollegan koskematon kopio toimii edelleen. Mitään ei estetty eikä varmenne vanhentunut. Joku korvasi päätepisteen isäntänimen tuolla ratkaistulla osoitteella, eikä palvelu enää vastaa siellä. Viety nimi on se osa, joka on rakennettu kestämään tämä muutos.

Profiilisi nimi ei ehkä ole se nimi, jota kysytään

Client VPN:stä viedyt profiilit sisältävät usein remote-random-hostname. Kun asetus on päällä, asiakas rakentaa kertakäyttöisen tunnisteen, liittää sen pisteellä päätepisteen nimeen ja ratkaisee yhdistetyn nimen. Päätepisteen vyöhykkeen jokerimerkintätietue vastaa mihin tahansa tunnisteeseen, minkä vuoksi keksitty etuliite ratkeaa edelleen ja siksi temppu pysyy näkymättömänä, kun yrität toistaa kyselyn käsin.

Kun siis liität päätepisteen nimen terminaaliin ja saat vastauksen, olet ratkaissut eri nimen kuin sen, jota asiakas käyttää yhdistäessään. Tämä ero ei ole profiilissa korjattava vika. Tunniste luodaan uudelleen tarkoituksella: asetus estää välimuisteja pitämästä vanhentunutta vastausta eikä koskaan tunnista konettasi tai istuntoasi.

Olen törmännyt yhteensopivuustapaukseen, jossa asiakas jättää asetuksen kokonaan huomiotta. AWS dokumentoi kiertotien: pidä todellinen päätepisteen nimi ja lisää eteen satunnainen merkkijono ja piste, käsittele sitä nimeämiskaavana eikä liitettävänä arvona. Sen soveltaminen vanhaan asiakkaaseen on järkevää; etuliitteisen merkkijonon kovakoodaaminen päätepisteeksi ei ole.

Miksi tallennettu vastaus ei voi pysyä oikeana

Client VPN -päätepisteiden osoitteita hallinnoi AWS ja ne muuttuvat ajan myötä, minkä parhaiden käytäntöjen dokumentaatio sanoo suoraan. Tallennettu vastaus on yhden ratkaisun tilannekuva. Profiili, joka kovakoodaa sen, muuttuu käytöstä poistettuun isäntään osoittavaksi profiiliksi heti, kun palvelu siirtyy, eikä vika näytä yleensä DNS:ltä: saat yhteysaikakatkaisun tai jumittuneen kättelyn, joten ihmiset jahtaavat reititystä ja varmenteita.

Sama vastaus tiedostossa /etc/hosts perii saman vanhenemisen ja ylimääräisen ongelman. hosts-merkintä selviää uudelleenkäynnistyksistä, uusista vienneistä ja 'asenna asiakas uudelleen' -korjauksista, joten vika palaa aina, kun osoite siirtyy. Olen nähnyt yhden olevan viikkoja vaaraton ja sitten kaatavan jokaisen sitä kantavan koneen, kun taas tuoreet asennukset yhdistyivät normaalisti. Tämä kahtiajako, yksi ryhmä epäonnistuu ja toinen on kunnossa samalla tilillä, on halvin vihje, jonka saat.

Rajaa satunnaistaminen oikein. Se tapahtuu yhteysyritystä kohden. Muodostettu tunneli ei ratkaise päätepistettään uudelleen, ei vaihda palvelinta kesken istunnon, eivätkä yksittäiset sovelluspyynnöt valitse kukin uutta VPN-isäntää. Vain seuraava yritys ratkaisee uudelleen, minkä vuoksi koko iltapäivän toimiva istunto ei kerro huomisaamusta mitään.

Mitä palvelu tarkistaa, kun tunneli nousee

Client VPN edellyttää, että yhdistetty osoite vastaa päätepisteen DNS-nimelle ratkaistua osoitetta. Tämä yksi vaatimus selittää useita toisiinsa liittymättömiltä näyttäviä vikoja: oma DNS-tietue, joka osoittaa muualle, oma frontend, joka välittää todelliseen päätepisteosoitteeseen, ja profiili, joka on kirjoitettu uudelleen raakaosoitteeksi. AWS dokumentoi oman tietueen ja välityksen yhdistelmän vikana uusien AWS-asiakkaiden kanssa. Tarkistus on kapea; se ei ole tuomio, että jokainen alias on kielletty.

Se ei ole yleinen sääntö VPN-protokollistakaan. Numeerinen remote on täysin kelvollinen tavallisessa OpenVPN-käyttöönotossa, ja monet toimivat niin. Rajoite tulee hallitusta järjestelystä, ei sen alla olevasta protokollasta.

Siksi varmenteen tarkistuksen löysääminen on väärä refleksi. Jos profiili epäonnistuu osoitteen vaihdon jälkeen, palvelimen tarkistuksen poistaminen siirtää virheen sen sijaan, että korjaisi ratkaisun tai osoitteen vastaavuusvaatimuksen, ja jättää asiakkaan, joka luottaa mihin tahansa. Pidä viety CA, palvelimen tarkistus ja molemminpuolisen todentamisen asetukset täsmälleen sellaisina kuin ne tulivat.

Sallitut listat, lähtevä liikenne ja yksityinen DNS ovat kolme eri ongelmaa

Palomuurisääntö, jonka on sallittava kohde ennen kannettavan yhdistämistä, koskee ulompaa kuuntelijaa. Anna verkon omistajalle päätepisteen nimi, kuljetus ja määritetty portti, ja kysy sitten, voiko heidän kontrollinsa seurata palvelun DNS-käyttäytymistä. Sääntö, joka pitää yhden tallennetun osoitteen, on tilannekuva kirjoittamattomalla vanhenemisella. Jos kontrolli hyväksyy vain muuttumattomat kohteet, ratkaise tämä aukko ennen käyttöönottoa sen sijaan, että kovakoodaisit vastauksen hiljaa.

Kumppanilla, joka tarvitsee kiinteän lähdeosoitteen tunnelin pystyttämisen jälkeen tehtäville pyynnöille, on eri vaatimus: lähtevä liikenne. Sivuston näkemä riippuu sovelluksen reitistä ja jaetun tunnelin käytännöstä, ei osoitteesta, johon asiakas yhdisti. Jaetun tunnelin liikenne ei välttämättä kosketa AWS:ää lainkaan.

Tunnelin sisäinen yksityinen DNS on kolmas kerros. Asiakkaille annettu ratkaisija vastaa sisäisiin nimiin yhteyden jälkeen; se ei voi ratkaista julkista päätepistettä ennen kuin tunneli on olemassa. Päätepisteen ratkaisuvika ja sisäisen sovelluksen ratkaisuvika tapahtuvat eri vaiheissa, ja niiden sekoittaminen vie sinut väärään lokiin.

Osoiteperhe kuuluu samaan listaan. IPv4-vastaus ei kerro mitään IPv6- tai kaksoispino-päätepisteen sallitusta polusta, joten yhdessä perheessä otettu tilannekuva ei ole todiste toisesta.

Tarkista yhteys kiinnittämättä mitään

Aloita profiilista sellaisena kuin se vietiin ja lue, mitä se todella pyytää:

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

Vertaa sitten kolmea asiaa: profiilissa olevaa päätepisteen nimeä, asiakkaan uudelle yritykselle ilmoittamaa osoitetta ja sitä, mihin nimi ratkeaa juuri nyt. Ratkeava nimi todistaa vain, että tietue vastaa; kuljetus ja todentaminen ovat erillisiä, eikä päätepisteen tarvitse vastata pingiin. Asiakkaan oma loki on ainoa lähde keskimmäiselle kohdalle, joten tallenna se yrityksen aikana, ei jälkeen.

Tänään vastaava osoite on todiste tästä päivästä; nimi on se, mitä palvelu pitää voimassa. Kirjaa havainto, lähetä se päätepisteen omistajalle ja jätä profiili osoittamaan nimeen.

Kaksi tapaa pois: varmenteen tarkistusten poistaminen jumittuneen kättelyn ohittamiseksi ja tunnisteiden pinoaminen päätepisteen nimen eteen toivoen, että yksi tarttuu. Tunniste ratkeaa jokerimerkintätietueen kautta tai ongelma on muualla. Jos oikein määritetty profiili epäonnistuu edelleen, lähetä täsmällinen kysely ja yhteystapahtuma, ei pidempää isäntänimeä.

Ennen kuin suljet asian: profiilissa on edelleen viety päätepisteen nimi, mikään hosts-tiedosto ei kiinnitä osoitetta, asiakkaan lokin remote vastaa nykyistä ratkaisua ja palomuurisääntö nimeää päätepisteen eikä osoitetta. Tämä on myös tila, joka annetaan seuraavalle henkilölle.