Két VPN láncolása: mit takar és mibe kerül

Két beágyazott alagút nem tesz névtelenné. Annyit tesznek, hogy két szolgáltató között osztják meg a megfigyeléseket, így egyikük sem látja egyszerre az otthoni címedet és az úti célodat. Ez valódi, de szűk előny, és olyan útvonalválasztási, DNS- és MTU-problémákkal jár, amelyek akkor jelentkeznek, amikor először támaszkodsz rá.

1. Döntsd el, mire kell a második ugrás

Írd le a célt egy mondatban, mielőtt bármit beállítasz. Ha a cél az, hogy a szolgáltatód ne lássa, mely oldalakat látogatod, egy alagút is eléri. Ha a cél az, hogy egyetlen szolgáltató se tudja összekapcsolni a címedet a forgalmaddal, kettő eléri. Ha a cél az, hogy senki ne tudjon azonosítani, oda semmilyen ugrásszám sem vezet.

A lánc csak olyan erős, amilyen a gyengébb szolgáltató naplója és a fióknyilvántartás, amelyet mindketten vezetnek. A fizetések, a regisztrációs e-mail és az alkalmazás telemetriája teljesen az alagúton kívül van.

2. Tedd elérhetővé a belső végpontot a külső alagúton keresztül

A szokásos hiba, hogy a belső alagút soha nem jön létre. A teljes alagutas külső kapcsolat birtokolja az alapértelmezett útvonalat, ezért a belső kliens saját végpontja felé tett kísérletét a külső alagút elnyeli, és eldobja vagy hurokba teszi. A belső végpontnak kifejezett útvonalra van szüksége a külső interfészen át, amelyet a belső kliens indulása előtt kell telepíteni. Különben a kézfogás versenyt fut az útvonallal, és veszít.

A WireGuard ugyanezt az ütközést mutatja a másik irányból. Minden peer AllowedIPs mezője dönti el, mely célok lépnek be abba az alagútba, ezért a minden címre igényt tartó belső interfész a külső végpontra is igényt tart, hacsak nem nyer egy pontosabb útvonal. A két interfészen átfedő AllowedIPs olyan beállítás, amelyben az egyik fél csendben veszít.

A konténerláncolás kifejezetté teszi a szétválasztást, a csapdát pedig nyilvánvalóvá. A saját névtérrel, saját alapértelmezett útvonallal és belső klienssel rendelkező konténer továbbítja azt, amit a hoszt küld neki; a hoszt magától nem kezdi el használni azt az útvonalat. Kapcsold be a továbbítást, adj hozzá útvonalat a konténer alagútjához, és irányítsd a szolgáltatást a konténer címére.

3. Tartsd a DNS-t ugyanazon az útvonalon

A DNS-nek oda kell utaznia, ahová a forgalom utazik. Ha a belső szolgáltató feloldókat küld, és a hoszt továbbra is a helyieket kérdezi, azok a lekérések pontosan azokat az oldalakat fedik fel, amelyeket az alagútnak el kellett volna rejtenie. Minden alagút-interfészen rögzítéssel ellenőrizd, ne a kliens állapotpaneljében bízz. Az itteni szivárgás normál böngészés közben láthatatlan, rögzítésben nyilvánvaló.

A megosztott DNS-tervek ezt nehezebbé teszik, mert egy helyi névre vonatkozó lekérés jogosan tartozhat az alagúton kívülre. A kivétellistát szándékosan írd meg, ne abból fedezd fel, hogy melyik feloldó válaszolt éppen.

4. Állítsd be az MTU-t, mielőtt a felhasználók helyetted felfedezik

Az MTU a másik előre jelezhető áldozat. Két beágyazás két fejlécet von le, és a külső alagút, amely már csökkentette az útvonal MTU-ját, kevesebb helyet hagy belül. A tünetek ismerősek: a kis kérések átmennek, a nagy átvitelek és a TLS-kézfogások elakadnak.

ip link set dev wg1 mtu 1280 a durva megoldás, és az MSS korlátozása a továbbítón a tisztább. A kapcsolat újrapróbálása egyáltalán nem megoldás.

5. Teszteld azt a hibát, amelyet valóban kapni fogsz

Szakítsd meg szándékosan a külső alagutat, és figyeld, mi történik. Az a lánc, amely csendben visszaesik közvetlen útvonalra, amikor a külső ugrás meghal, rosszabb, mint a lánc nélküli állapot, mert pontosan abban a pillanatban szivárog, amikor azt hitted, fedezve vagy. A célzott viselkedés egy kill switch, amely leállítja az összes forgalmat. Jegyezd fel az eredményt, mert nem akarod majd egy incidens közepén újra felfedezni.

A késleltetés és a második hibahely az állandó költség. Két ugrás két támogatási sort is jelent, amikor valami alkalmatlan órában elromlik.