Верига от две VPN: какво скрива и какво струва

Два вложени тунела не ви правят анонимни. Те разделят наблюденията между два доставчика, така че нито един не вижда домашния ви адрес и дестинацията ви заедно. Това е истинско, но тясно предимство и идва с проблеми с маршрутизацията, DNS и MTU, които се появяват първия път, когато разчитате на него.

1. Решете за какво е вторият хоп

Напишете целта в едно изречение, преди да настроите каквото и да е. Ако целта е доставчикът ви да не вижда кои сайтове посещавате, един тунел я постига. Ако е нито един доставчик да не може да свърже адреса ви с трафика ви, два тунела го правят. Ако е никой да не може да ви идентифицира, никакъв брой хопове не стига дотам.

Веригата е само толкова силна, колкото са журналите на по-слабия доставчик и записите на акаунти, които и двамата пазят. Плащанията, имейлът за регистрация и телеметрията на приложението стоят изцяло извън тунела.

2. Направете вътрешния край достъпен през външния тунел

Обичайният провал е вътрешният тунел никога да не се установи. Външна връзка с пълен тунел притежава маршрута по подразбиране, затова опитът на вътрешния клиент да достигне собствения си край се поглъща от външния тунел и се изпуска или зацикля. Вътрешният край се нуждае от явен маршрут през външния интерфейс, инсталиран преди стартирането на вътрешния клиент. Иначе ръкостискането се състезава с маршрута и губи.

WireGuard показва същия конфликт от другата посока. Всеки peer има AllowedIPs, който решава кои дестинации влизат в този тунел, затова вътрешен интерфейс, който претендира за всеки адрес, претендира и за външния край, освен ако не спечели по-конкретен маршрут. Припокриващи се AllowedIPs в два интерфейса са конфигурация, в която едната страна тихо губи.

Верижното свързване на контейнери прави разделението явно, а капана — очевиден. Контейнер със собствено пространство от имена, собствен маршрут по подразбиране и клиент вътре в него препраща това, което хостът му изпраща; хостът сам не започва да използва този път. Включете препращането, добавете маршрут за тунела на контейнера и насочете услугата към адреса на контейнера.

3. Дръжте DNS на същия път

DNS трябва да пътува там, където пътува трафикът. Ако вътрешният доставчик предлага резолвери, а хостът все още пита локалните, тези заявки разкриват точно сайтовете, които тунелът е трябвало да скрие. Проверявайте със заснемане на всеки интерфейс на тунела, вместо да вярвате на панела със състоянието на клиента. Изтичане тук е невидимо при нормално сърфиране и очевидно при заснемане.

Разделените DNS дизайни правят това по-трудно, защото заявка за локално име може законно да принадлежи извън тунела. Напишете списъка с изключения нарочно, вместо да го откривате от който и да е резолвер случайно отговорил.

4. Задайте MTU, преди потребителите да го открият вместо вас

MTU е другата предвидима жертва. Двете инкапсулации изваждат две заглавки и външен тунел, който вече е намалил MTU на пътя, оставя по-малко място отвътре. Симптомите са познати: малките заявки минават, големите трансфери и TLS ръкостисканията забиват.

ip link set dev wg1 mtu 1280 е грубото решение, а ограничаването на MSS на препращача е по-спретнатото. Повторен опит за връзка изобщо не е решение.

5. Тествайте отказа, който наистина ще получите

Прекъснете външния тунел нарочно и наблюдавайте какво се случва. Верига, която тихо се връща към директен път, когато външният хоп умре, е по-лоша от липса на верига, защото изтича точно в момента, в който сте вярвали, че сте защитени. Желаното поведение е kill switch, който спира целия трафик. Запишете резултата, защото няма да искате да го откривате отново по средата на инцидент.

Забавянето и втората точка на отказ са постоянните разходи. Два хопа означават и две опашки за поддръжка, когато нещо се счупи в неудобен час.