Kaksi sisäkkäistä tunnelia ei tee sinusta anonyymiä. Ne jakavat havainnot kahden palveluntarjoajan kesken, joten kumpikaan ei näe kotiosoitettasi ja määränpäätäsi samanaikaisesti. Se on todellinen mutta kapea hyöty, ja sen mukana tulevat reititys-, DNS- ja MTU-ongelmat, jotka ilmenevät ensimmäisen kerran, kun luotat siihen.

1. Päätä, mihin toinen hyppy on tarkoitettu

Kirjoita tavoite yhteen lauseeseen ennen kuin määrität mitään. Jos tavoite on, ettei operaattorisi näe käymiesi sivustojen osoitteita, yksi tunneli saavuttaa sen. Jos tavoite on, ettei yksikään palveluntarjoaja pysty yhdistämään osoitettasi liikenteeseesi, kaksi tekee sen. Jos tavoite on, ettei kukaan pysty tunnistamaan sinua, mikään hyppyjen määrä ei johda sinne.

Ketju on vain yhtä vahva kuin heikomman palveluntarjoajan lokit ja ne tilit, joita molemmat pitävät. Maksut, rekisteröitymissähköposti ja sovelluksen telemetria ovat kokonaan tunnelin ulkopuolella.

2. Tee sisemmästä päästä tavoitettava ulomman tunnelin kautta

Tavallinen epäonnistuminen on, että sisempi tunneli ei koskaan muodostu. Täystunnelin ulompi yhteys omistaa oletusreitin, joten sisemmän asiakkaan yritys tavoittaa oma päänsä nielaistaan ulompaan tunneliin ja pudotetaan tai laitetaan silmukkaan. Sisempi pää tarvitsee eksplisiittisen reitin ulomman rajapinnan kautta, asennettuna ennen sisemmän asiakkaan käynnistymistä. Muuten kättely kilpailee reitin kanssa ja häviää.

WireGuard näyttää saman ristiriidan toisesta suunnasta. Kunkin peerin AllowedIPs päättää, mitkä kohteet tulevat siihen tunneliin, joten sisempi rajapinta, joka vaatii kaikki osoitteet, vaatii myös ulomman pään, ellei tarkempi reitti voita. Kahden rajapinnan päällekkäiset AllowedIPs ovat kokoonpano, jossa toinen puoli häviää äänettömästi.

Konttien ketjuttaminen tekee erottelusta eksplisiittisen ja ansasta ilmeisen. Kontti, jolla on oma nimiavaruutensa, oma oletusreittinsä ja asiakas sisällään, välittää sen, mitä isäntä sille lähettää; isäntä ei ala itse käyttää sitä polkua. Ota välitys käyttöön, lisää reitti kontin tunnelille ja osoita palvelu kontin osoitteeseen.

3. Pidä DNS samalla polulla

DNS:n on matkattava sinne, minne liikenne matkaa. Jos sisempi palveluntarjoaja tarjoaa resolverit ja isäntä kysyy yhä paikallisia, ne haut paljastavat juuri ne sivustot, jotka tunneli oli tarkoitettu kätkemään. Tarkista kaappauksella jokaisella tunnelin rajapinnalla sen sijaan, että luottaisit asiakkaan tilapaneeliin. Vuoto on täällä näkymätön tavallisessa selailussa ja ilmeinen kaappauksessa.

Jaetun DNS:n ratkaisut vaikeuttavat tätä, koska paikallisen nimen kysely voi laillisesti kuulua tunnelin ulkopuolelle. Kirjoita poikkeusluettelo tarkoituksella sen sijaan, että löytäisit sen siitä, mikä resolver sattui vastaamaan.

4. Aseta MTU ennen kuin käyttäjät löytävät sen puolestasi

MTU on toinen ennustettava uhri. Kaksi kapselointia vähentää kaksi otsikkoa, ja ulompi tunneli, joka on jo laskenut polun MTU:n, jättää sisään vähemmän tilaa. Oireet ovat tuttuja: pienet pyynnöt onnistuvat, suuret siirrot ja TLS-kättelyt pysähtyvät.

ip link set dev wg1 mtu 1280 on karkea korjaus, ja MSS:n rajaaminen välittäjällä on siistimpi. Yhteyden uudelleen yrittäminen ei ole korjaus lainkaan.

5. Testaa vika, joka sinulle todella tulee

Katkaise ulompi tunneli tahallasi ja katso, mitä tapahtuu. Ketju, joka putoaa äänettömästi suoralle reitille ulomman hypyn kuollessa, on huonompi kuin ei ketjua lainkaan, koska se vuotaa juuri sillä hetkellä, jolloin luulit olevasi suojattu. Tavoiteltava käytös on kill switch, joka pysäyttää kaiken liikenteen. Kirjaa tulos, sillä et halua löytää sitä uudelleen kesken tilanteen.

Viive ja toinen vikapiste ovat pysyvät kustannukset. Kaksi hyppyä tarkoittaa myös kahta tukijonoa, kun jotain hajoaa sopimattomaan aikaan.

Aiheeseen liittyvät artikkelit