Повезивање два VPN-а у ланац: шта скрива и колико кошта

Два угнежђена тунела не чине вас анонимним. Она деле запажања између два провајдера, па ниједан не види истовремено вашу кућну адресу и ваше одредиште. То је стварна, али уска предност, и долази с проблемима рутирања, DNS-а и MTU-а који се појаве први пут када се на њу ослоните.

1. Одлучите чему служи други скок

Запишите циљ у једној реченици пре него што било шта конфигуришете. Ако је циљ да ваш ISP не види које странице посећујете, један тунел то постиже. Ако је циљ да ниједан провајдер сам не може повезати вашу адресу с вашим саобраћајем, потребна су два. Ако је циљ да вас нико не може идентификовати, ниједан број скокова тамо не води.

Ланац је јак онолико колико је јако логовање слабијег провајдера и евиденција налога коју обојица воде. Плаћања, е-пошта при регистрацији и телеметрија апликације стоје потпуно изван тунела.

2. Учините унутрашњу крајњу тачку доступном кроз спољни тунел

Уобичајени квар је да се унутрашњи тунел никада не успостави. Спољна веза у режиму пуног тунела поседује подразумевану руту, па покушај унутрашњег клијента да достигне сопствену крајњу тачку бива прогутан од спољног тунела и одбачен или заврши у петљи. Унутрашњој крајњој тачки треба изричита рута кроз спољни интерфејс, уграђена пре него што се унутрашњи клијент покрене. Иначе се руковање трка с рутом и губи.

WireGuard показује исти сукоб из другог смера. Код сваког пира AllowedIPs одлучује која одредишта улазе у тај тунел, па унутрашњи интерфејс који тражи сваку адресу тражи и спољну крајњу тачку, осим ако победи специфичнија рута. Преклапајући AllowedIPs на два интерфејса је конфигурација у којој једна страна тихо губи.

Ланчано повезивање контејнера чини раздвајање јасним, а замку очигледном. Контејнер са сопственим именским простором, сопственом подразумеваном рутом и клијентом унутра прослеђује оно што му хост пошаље; хост сам не почиње да користи тај пут. Укључите прослеђивање, додајте руту за тунел контејнера и усмерите услугу на адресу контејнера.

3. Држите DNS на истом путу

DNS мора да путује тамо куда путује саобраћај. Ако унутрашњи провајдер гура резолвере, а хост и даље пита локалне, ти упити откривају тачно оне странице које је тунел требало да сакрије. Проверавајте снимком на сваком интерфејсу тунела уместо да верујете статусном панелу клијента. Цурење овде је невидљиво током обичног прегледања, а очигледно у снимку.

Подељени DNS дизајни ово отежавају, јер упит за локално име може легитимно да припада изван тунела. Напишите листу изузетака намерно, уместо да је откријете преко резолвера који је случајно одговорио.

4. Поставите MTU пре него што корисници открију уместо вас

MTU је друга предвидива жртва. Две инкапсулације одузимају два заглавља, а спољни тунел који је већ снизио MTU пута оставља мање простора унутра. Симптоми су познати: мали захтеви пролазе, велики преноси и TLS руковања се заглуше.

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

5. Тестирајте квар који ћете заиста добити

Намерно сломите спољни тунел и гледајте шта се дешава. Ланац који тихо падне на директан пут када спољни скок умре гори је од никаквог ланца, јер цури тачно у тренутку када сте веровали да сте покривени. Kill switch који зауставља сав саобраћај је понашање коме треба тежити. Запишите резултат, јер га нећете хтети поново откривати усред инцидента.

Кашњење и друга тачка отказа су стални трошкови. Два скока значе и два реда подршке када се нешто поквари у незгодан час.