Mitä STUN-vastaus paljastaa, kun VPN toimii reitittimessä

Kun tunneli asuu reitittimessä, selainta ajavalla koneella ei ole lainkaan tunnelirajapintaa. Kysy siltä koneelta sen paikallisia osoitteita ja saat yksityisen LAN-osoitteen ja takaisinkytkennän, ei mitään VPN-osoitetta muistuttavaa. Silti toisella puolella oleva STUN-palvelin voi yhä raportoida jotain merkityksellistä polusta, ja se, mitä se raportoi, riippuu täysin siitä, miten juuri tuo pyyntö reititettiin ja käännettiin.

Juuri tämä osa kannattaa käydä hitaasti läpi. „Selain ei omista VPN-osoitetta“ vastaa rajapintoja koskevaan kysymykseen, kun taas heijastettu osoite on vastaus käännöksen kautta kulkevasta polusta. Näiden kahden sekoittaminen tuottaa itsevarmoja päätelmiä paljastumisesta, joita todisteet eivät tue.

Kaksi laitetta, kaksi rajapintajoukkoa

Reititinpohjaisessa kokoonpanossa tunneli päättyy reitittimeen ja LAN-asiakas lähettää tavallista liikennettä oletusyhdyskäytävälleen. Asiakkaan rajapintaluettelo pysyy lyhyenä: yksi yksityinen osoite, ehkä toinen toiselle verkolle, ja takaisinkytkentä. Riski ei ole siinä, että yksi niistä sattuu olemaan tunneliosoite; riski on siinä, että pyyntö lähtee polkua, jota et valinnut.

Kysy asiakkaalta minkä polun tietty kohde ottaisi sen sijaan, että kysyisit mitä rajapintoja on olemassa. Vastaus nimeää yhdyskäytävän ja lähdeosoitteen, jota ydin käyttäisi, ja se on jo valaisevampaa kuin mikään osoiteluettelo.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Dokumentaatiovaraukset ovat hyviä testikohteita, koska ne eivät koskaan ratkea oikeaksi palveluksi. Vertaa, mitä asiakas sanoo, siihen, mitä reititin sanoo, ja pidä mitä tahansa eroa todisteena siitä, että käytäntöpohjainen reititys, jaetun tunnelin sääntö tai toinen oletusreitti tekee jotain, jota et ottanut huomioon.

Mitä Binding-vastaus saa sanoa

RFC 8489 määrittelee Binding-pyynnön ja -vastauksen, jossa palvelin raportoi kyseiselle pyynnölle havaitsemansa lähdekuljetusosoitteen. Se on väite yhdestä viisikosta yhdellä hetkellä, ei asiakkaan rajapintojen laskenta. Siksi kaikki kiinnostava tapahtuu asiakkaan ja havaintopisteen välissä.

Tämän aukon täyttävät reititys ja käännös. Reititin, joka tekee lähtevälle liikenteelle lähde-NATin, korvaa asiakkaan yksityisen lähteen omalla osoitteellaan lähtevällä rajapinnalla. Jos tuo rajapinta on tunneli, heijastin näkee tunneliosoitteen. Jos paketti jätettiin tunnelin ulkopuolelle, heijastin näkee sen, mitä WAN-käännös tuotti. Sama asiakas, sama heijastin, eri vastaus.

Kolme tapausta, jotka näyttävät samalta eivätkä ole

Hyödyllinen ero ei ole julkinen vastaan yksityinen, vaan se, mikä valvontapiste käsitteli paketin. Käy tapaukset läpi reitittimen omat taulukot avoinna, koska yksi selain voi tuottaa kaikki kolme riippuen säännöstä, jonka kirjoittamisen unohdit.

Vain toinen tapaus rikkoo vaatimuksen, ettei tietty liikenne koskaan lähde suoraan, ja vain ensimmäinen ja kolmas paljastavat tunnelin puoleisen tunnisteen. Mikään kolmesta rivistä ei ole väite tietyn palveluntarjoajan käyttäytymisestä: se, onko yksityinen heijastin ylipäätään tavoitettavissa, riippuu reitityksestä, vastapuolen sallituista IP-osoitteista ja palomuurikäytännöstä molemmissa päissä.

Tilin omistaminen samalla palveluntarjoajalla ei todista mitään tästä. Kannattaa myös muistaa, että reititetty pyyntö voi säilyttää asiakkaan LAN-lähteen, jos mikään ei käännä sitä, joten lähdekenttä on jäljitettävä eikä oletettava topologiakaaviosta.

Kerääminen ei ole valitsemista

WebRTC kerää ehdokasosoitteita kokeiltaviksi, eikä diagnostisessa luettelossa näkyvä ehdokas välttämättä koskaan kuljeta mediaa. Luettelon lukeminen niin, että „tämän vastapuoli oppi“, liioittelee todisteita. Valittu pari on se, joka todella kuljetti istunnon, ja se sijaitsee toisessa kentässä.

HTTPS-lähtötarkistus vastaa vielä yhteen kysymykseen: lähdeosoite, jonka verkkopalvelin näki kyseiselle pyynnölle. Se on hyödyllinen ristiintarkistus juuri siksi, että se käyttää eri protokollaa ja usein eri kohdetta kuin UDP-heijastin, ja näiden kahden ero osoittaa yleensä reitityssääntöön eikä vikaan.

Päätä käytäntö ja lue sitten vastaus

Kirjoita aikomus ennen testausta: mikä liikenne on käytettävä tunnelia, mikä saa lähteä suoraan, mitkä osoiteperheet kuuluvat piiriin ja mitä pitäisi tapahtua, kun tunneli on alhaalla. Ilman tätä perustasoa jokainen havainto on monitulkintainen, koska et voi erottaa vuotoa polusta, jonka tietoisesti sallit.

Kysy sitten yksi kysymys kerrallaan. Minkä polun tämä kohde ottaa. Mitä osoitetta tämä heijastin raportoi. Minkä ehdokasparin istunto valitsi. Pidä vastaukset käytännön vieressä ja päivää ne, koska laiteohjelmistopäivitys voi muuttaa oletuskäyttäytymistä tavalla, joka hiljaa mitätöi viime vuoden päätelmän.

Reititin on yhä vahva valvontapiste, koska se näkee liikennettä, jota asiakas ei voi ohittaa konfiguroimatta itseään uudelleen. Se ei ole lupaus siitä, ettei mikään kenttä missään sovellusprotokollassa paljasta mitään, eikä se korvaa niiden polkujen kirjaamista, jotka päätit sallia.