Twee VPN's in ketting: wat dit verberg en wat dit kos

Twee geneste tonnels maak jou nie anoniem nie. Hulle verdeel die waarnemings tussen twee verskaffers, so nie een van hulle sien jou tuisadres en jou bestemming saam nie. Dit is ’n egte maar smal voordeel, en dit kom saam met roetering-, DNS- en MTU-probleme wat die eerste keer opduik wanneer jy daarop staatmaak.

1. Besluit waarvoor die tweede hop is

Skryf die doel in een sin voordat jy iets opstel. As die doel is dat jou ISP nie kan sien watter werwe jy besoek nie, bereik een tonnel dit. As dit is dat geen enkele verskaffer jou adres aan jou verkeer kan koppel nie, doen twee dit. As dit is dat niemand jou kan identifiseer nie, kom geen aantal hoje daar nie.

Die ketting is net so sterk soos die swakker verskaffer se logs en die rekordhouding wat albei hou. Betalings, aanmeld-e-pos en app-telemetrie sit heeltemal buite die tonnel.

2. Maak die binneste eindpunt bereikbaar deur die buitenste tonnel

Die gewone faling is dat die binneste tonnel nooit opgebou word nie. ’n Voltonnel-verbinding aan die buitekant besit die standaardroete, so die binneste kliënt se poging om sy eie eindpunt te bereik word deur die buitenste tonnel ingesluk en laat val of in ’n lus gestuur. Die binneste eindpunt het ’n eksplisiete roete deur die buitenste koppelvlak nodig, geïnstalleer voordat die binneste kliënt begin. Anders wedloop die handdruk teen die roete en verloor.

WireGuard wys dieselfde konflik uit die ander rigting. Elke peer se AllowedIPs bepaal watter bestemmings daardie tonnel binnegaan, so ’n binneste koppelvlak wat elke adres opeis, eis ook die buitenste eindpunt op tensy ’n meer spesifieke roete wen. Oorvleuelende AllowedIPs oor twee koppelvlakke is ’n opstelling waarin een kant stilweg verloor.

Houerketting maak die skeiding duidelik en die lokval ooglopend. ’n Houer met sy eie naamruimte, sy eie standaardroete en ’n kliënt binne-in stuur deur wat die gasheer na hom stuur; die gasheer begin nie self daardie pad gebruik nie. Aktiveer deurvoer, voeg ’n roete vir die houer se tonnel by, en rig die diens na die houeradres.

3. Hou DNS op dieselfde pad

DNS moet reis waar die verkeer reis. As die binneste verskaffer oplossers stuur en die gasheer vra steeds die plaaslike oplossers, dan verraai daardie opsoeke presies die werwe wat die tonnel moes verberg. Kontroleer met ’n opname op elke tonnelkoppelvlak eerder as om die kliënt se statuspaneel te vertrou. ’n Lek hier is onsigbaar tydens gewone blaai en duidelik in ’n opname.

Verdeelde DNS-ontwerpe maak dit moeiliker, want ’n navraag vir ’n plaaslike naam kan wettig buite die tonnel hoort. Skryf die uitsonderingslys doelbewus neer eerder as om dit te ontdek by watter oplosser ook al toevallig geantwoord het.

4. Stel MTU voordat gebruikers dit vir jou uitvind

MTU is die ander voorspelbare slagoffer. Twee inkapselings trek twee opskrifte af, en ’n buitenste tonnel wat die pad se MTU reeds verlaag het, laat minder ruimte binne. Die simptome is bekend: klein versoeke slaag, groot oordragte en TLS-handdrukke stol.

ip link set dev wg1 mtu 1280 is die growwe oplossing, en die aftak van MSS op die deurvoerder is die netter een. Om die verbinding weer te probeer is glad nie ’n oplossing nie.

5. Toets die faling wat jy werklik gaan kry

Breek die buitenste tonnel doelbewus en kyk wat gebeur. ’n Ketting wat stilweg na ’n direkte pad terugval wanneer die buitenste hop sterf, is slegter as geen ketting nie, want dit lek juis die oomblik wanneer jy gedink het jy is gedek. ’n Doodskakelaar wat alle verkeer stop, is die gedrag om na te streef. Teken die resultaat aan, want jy sal dit nie midde-in ’n voorval wil herontdek nie.

Latensie en ’n tweede foutpunt is die staande koste. Twee hoje beteken ook twee ondersteuningsrye wanneer iets op ’n ongeleë uur breek.