Łączenie dwóch VPN-ów: co to ukrywa i ile kosztuje

Dwa zagnieżdżone tunele nie czynią cię anonimowym. Dzielą obserwacje między dwóch dostawców, więc żaden z nich nie widzi jednocześnie twojego domowego adresu i celu. To prawdziwa, ale wąska korzyść, a przychodzi z problemami z routingiem, DNS i MTU, które pojawiają się za pierwszym razem, gdy na niej polegasz.

1. Ustal, czemu ma służyć drugi przeskok

Zapisz cel w jednym zdaniu, zanim cokolwiek skonfigurujesz. Jeśli chodzi o to, by twój ISP nie widział, jakie strony odwiedzasz, wystarczy jeden tunel. Jeśli o to, by żaden pojedynczy dostawca nie mógł powiązać twojego adresu z ruchem, potrzebne są dwa. Jeśli o to, by nikt nie mógł cię zidentyfikować, żadna liczba przeskoków tam nie doprowadzi.

Łańcuch jest tak mocny jak logowanie słabszego dostawcy i prowadzone przez obu rejestry kont. Płatności, e-mail przy rejestracji i telemetria aplikacji znajdują się całkowicie poza tunelem.

2. Udostępnij wewnętrzny punkt końcowy przez zewnętrzny tunel

Typowa awaria polega na tym, że wewnętrzny tunel nigdy się nie zestawia. Zewnętrzne połączenie w trybie pełnego tunelu przejmuje trasę domyślną, więc próba dotarcia wewnętrznego klienta do własnego punktu końcowego zostaje pochłonięta przez tunel zewnętrzny i odrzucona albo zapętlona. Wewnętrzny punkt końcowy potrzebuje jawnej trasy przez interfejs zewnętrzny, zainstalowanej przed startem wewnętrznego klienta. Inaczej uzgadnianie ściga się z trasą i przegrywa.

U każdego peera AllowedIPs decyduje o tym, które cele wchodzą do tego tunelu, więc wewnętrzny interfejs roszczący sobie każdy adres roszczy sobie także zewnętrzny punkt końcowy, chyba że wygra bardziej szczegółowa trasa. Nakładające się AllowedIPs na dwóch interfejsach to konfiguracja, w której jedna strona po cichu przegrywa.

Łączenie kontenerów czyni rozdział jawnym, a pułapkę oczywistą. Kontener z własną przestrzenią nazw, własną trasą domyślną i klientem w środku przekazuje dalej to, co wysyła mu host; host nie zaczyna sam z tej ścieżki korzystać. Włącz przekazywanie, dodaj trasę dla tunelu kontenera i skieruj usługę na adres kontenera.

3. Trzymaj DNS na tej samej ścieżce

DNS musi podróżować tam, gdzie podróżuje ruch. Jeśli wewnętrzny dostawca wypycha resolvery, a host nadal pyta lokalne, te zapytania ujawniają dokładnie te strony, które tunel miał ukryć. Sprawdzaj przechwytem na każdym interfejsie tunelu, zamiast ufać panelowi statusu klienta. Wyciek tutaj jest niewidoczny podczas zwykłego przeglądania i oczywisty w przechwycie.

Projekty z podziałem DNS utrudniają to, bo zapytanie o lokalną nazwę może zgodnie z prawem należeć poza tunel. Zapisz listę wyjątków świadomie, zamiast odkrywać ją na podstawie tego, który resolver akurat odpowiedział.

4. Ustaw MTU, zanim użytkownicy zrobią to za ciebie

MTU to druga przewidywalna ofiara. Dwie enkapsulacje odejmują dwa nagłówki, a zewnętrzny tunel, który już obniżył MTU ścieżki, zostawia mniej miejsca w środku. Objawy są znane: małe żądania przechodzą, duże transfery i uzgadnianie TLS się zatrzymują.

ip link set dev wg1 mtu 1280 jest tępym rozwiązaniem, a przycinanie MSS na forwarderze jest schludniejsze. Ponawianie połączenia to nie żadne rozwiązanie.

5. Przetestuj awarię, którą naprawdę dostaniesz

Zepsuj celowo zewnętrzny tunel i patrz, co się dzieje. Łańcuch, który po cichu wraca do ścieżki bezpośredniej, gdy zewnętrzny przeskok padnie, jest gorszy niż brak łańcucha, bo wycieka dokładnie w chwili, w której wierzyłeś, że jesteś osłonięty. Kill switch zatrzymujący cały ruch to zachowanie, do którego warto dążyć. Zapisz wynik, bo nie będziesz chciał odkrywać go ponownie w środku incydentu.

Opóźnienie i drugi punkt awarii to stałe koszty. Dwa przeskoki oznaczają też dwie kolejki wsparcia, gdy coś padnie o niewygodnej porze.