Maantieteellinen DNS ja anycast: saamasi VPN-sisääntulon tarkistaminen

Läheinen DNS-vastaus tuntuu ratkaistulta ongelmalta, kunnes yhteys laskeutuu muualle. Maantieteellinen DNS ja anycast yrittävät molemmat lyhentää polkua, ja ne tekevät sen päätöksen eri tiedoista. Kumpikaan ei takaa, että yhdyskäytävä, jolle päädyt, on tavoitettavissa, että se esittää identiteetin, jota asiakkaasi odottaa, tai että istuntosi kestää solmun vaihdon. Alla olevat tarkistukset erottavat nämä neljä kysymystä.

Tarkista, kenen sijainnin ratkaisija oikeastaan ilmoittaa

Autoritatiivinen palvelin, joka vastaa topologiasta riippuvaan kyselyyn, näkee tavallisesti kysyneen rekursiivisen ratkaisijan osoitteen, ei nimen kirjoittaneen henkilön osoitetta. Keskitetty ratkaisija voi sijaita kaukana palvelemistaan asiakkaista, ja vastaus heijastaa ratkaisijaa eikä heitä. Se ei ole vika; näin protokolla käyttäytyy, ellei lisätietoja anneta. EDNS-asiakasaliverkon määrittely kuvaa sekä rajoituksen että valinnaisen korjauksen.

EDNS-asiakasaliverkko voi välittää lähiverkon tietoja, kun jokainen osapuoli tukee sitä ja ottaa sen käyttöön. Se on valinnainen, sillä on seurauksia yksityisyydelle ja välimuistille, eikä se ole lupa olettaa, että mikä tahansa julkinen ratkaisija ilmoittaa käyttäjän tarkan sijainnin. Kysy ratkaisijoiden ylläpitäjiltä ennen kuin suunnittelet sen varaan.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Tarkista, mitä anycast-reititys päätti

Anycastissa useat sijainnit ilmoittavat tavoitettavuudesta yhdelle palveluosoitteelle, ja verkko toimittaa jokaisen asiakkaan sille solmulle, jota sen reititys suosii. Sen valinnan tekevät BGP ja ympäröivä käytäntö, eivät etäisyys kartalla. Myöskään topologinen läheisyys ei yleensä merkitse parempaa edestakaista suorituskykyä, koska lyhyeltä näyttävä polku voi olla ruuhkautunut tai epäsymmetrinen. Saamasi osoite ei kerro mitään siitä, mikä solmu vastasi.

Vahvista palvelusijainti palvelun puolelta tai vastauksesta, joka nimeää sen, älä pelkästään DNS-vastauksesta. traceroute -n 198.51.100.20 näyttää polun, jonka kuljit, eikä silti nimeä isäntää sen päässä, joten lue se polkuna äläkä vastauksena.

Tarkista, että istunto kestää solmun vaihdon

DNS-kysely on lyhyt ja VPN-istunto pitkä, ja niillä on täysin erilaiset tilavaatimukset. Reititys voi siirtyä kesken istunnon, ja kun se tekee niin, myöhemmät paketit voivat saapua solmuun, joka ei ole koskaan nähnyt tunneliasi. Onko se kestettävissä, riippuu toteutuksesta: jaettu tila, tarkoituksellinen uudelleenyhdistäminen tai dokumentoitu vika. Pelkkä osoite ei tarjoa mitään niistä.

Tarkkaile siirtymää sen sijaan, että olettaisit sen. sudo tcpdump -ni any -c 20 esp näyttää ulommat paketit polun muuttuessa, ja äkillinen muutos vertaisosoitteessa on itse siirtymä. Määrittele aiottu käyttäytyminen nimenomaisesti ajamallesi toteutukselle ja testaa se sitten pakottamalla polun muutos. Jos suunnittelu olettaa istunnon replikoinnin, nimeä mekanismi ja nimeä vika, jota se ei kata.

Tarkista, että identiteetti täsmää edelleen

Jokaisen sisääntulon on esitettävä identiteetti, jota asiakasprofiilisi odottaa. Palvelun nimelle myönnetty varmenne toimii solmujen yli, kun taas solmukohtaiset varmenteet pakottavat asiakkaan hyväksymään jotain uutta, ja juuri siinä käyttäjät oppivat napsauttamaan varoitusten läpi. Pidä odotettu identiteetti ja profiili sisääntulomallin mukaisina.

Tarkista se asiakkaalta, joka päätyi epätavalliseen solmuun, koska juuri siinä tapauksessa solmukohtainen varmenne tulee näkyviin. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com tulostaa ketjun ja nimet, ja juuri sitä asiakas vertaa. Päätä sitten, pitääkö profiilia kaventaa vai varmennemallia muuttaa.

Tarkista kirjaus, älä vain ensimmäistä vastausta

Arvioi kolme skenaariota ja kirjoita kuhunkin neljä tosiseikkaa: normaali sisääntulo, yksi tavoittamaton sijainti ja sovittu palautumistapaus. Neljä tosiseikkaa ovat käytetty ratkaisija, palautettu osoite, palvellut sijainti ja tuore sovellustulos. Tämä kirjaus erottaa DNS-valinnan ongelman yhdyskäytävän ongelmasta, reititysongelmasta tai istunnon tilan ongelmasta. Ilman sitä kaikki neljä näyttävät asiakkaan puolelta samalta.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Aja skenaariot edustavista liityntäverkoista etkä vain toimistosta, koska koko kysymys on siitä, mihin sisääntuloon eri asiakkaat todella päätyvät. Yksi verkko on yhden otos.