Twa VPN's oaninoar keppelje: wat it ferberget en wat it kostet

Twa neste tunnels meitsje dy net anonimus. Se ferdiele de waarnimmings oer twa oanbieders, sadat gjinien fan beiden dyn thúsadres en dyn bestimming tagelyk sjocht. Dat is in echt mar smel foardiel, en it komt mei routing-, DNS- en MTU-problemen dy't de earste kear opkomme as do derop fertroust.

1. Beslis wêr't de twadde hop foar is

Skriuw it doel yn ien sin op foardat do eat konfigurearrest. As it doel is dat dyn ISP net sjen kin hokker siden do besykest, berikt ien tunnel dat. As it doel is dat gjin inkele oanbieder dyn adres oan dyn ferkear keppelje kin, dogge twa dat. As it doel is dat nimmen dy identifisearje kin, komt gjin oantal hops der.

De keatling is mar sa sterk as de logs fan 'e swakkere oanbieder en de akkountrecords dy't beide byhâlde. Betellingen, oanmeld-e-post en app-telemetry steane folslein bûten de tunnel.

2. Meitsje it binnenste einpunt berikber troch de bûtenste tunnel

De gewoane mislearring is dat de binnenste tunnel nea ta stân komt. In bûtenferbining mei folsleine tunnel hat de standertrûte, dus it besykjen fan 'e binnenste klant om syn eigen einpunt te berikken wurdt troch de bûtenste tunnel opslokt en weilitten of yn in lus set. It binnenste einpunt hat in eksplisite rûte troch de bûtenste interface nedich, ynstallearre foardat de binnenste klant start. Oars racet de handshake mei de rûte en ferliest.

WireGuard lit itselde konflikt fan 'e oare kant sjen. Elke peer syn AllowedIPs beslút hokker bestimmingen dy tunnel yngeane, dus in binnenste interface dy't elk adres opeasket, easket ek it bûtenste einpunt op, útsein as in mear spesifike rûte wint. Oerlappende AllowedIPs oer twa interfaces is in konfiguraasje wêryn't ien kant stil ferliest.

Containerkeatling makket de skieding eksplisyt en de falstrik fanselssprekkend. In container mei syn eigen nammeromte, syn eigen standertrûte en in klant deryn stjoert troch wat de host him stjoert; de host begjint sels net dy wei te brûken. Skeakelje trochstjoering yn, foegje in rûte ta foar de tunnel fan 'e container en rjochtsje de tsjinst op it containeradres.

3. Hâld DNS op itselde paad

DNS moat reizgje wêr't it ferkear reizget. As de binnenste oanbieder resolvers leveret en de host freget noch hieltyd de lokale, dan ferriede dy opfregingen krekt de siden dy't de tunnel ferbergje moast. Kontrolearje mei in opname op elke tunnelinterface ynstee fan te fertrouwen op it statuspaneel fan 'e klant. In lek hjir is ûnsichtber by normaal browsen en dúdlik yn in opname.

Split-DNS-ûntwerpen meitsje dit dreger, want in fraach nei in lokale namme kin legitimaal bûten de tunnel hearre. Skriuw de útsûnderingslist bewust op ynstee fan dy te ûntdekken oan 'e hân fan hokker resolver tafallich antwurde.

4. Stel de MTU yn foardat brûkers it foar dy ûntdekke

MTU is de oare foarsisbere slachtoffer. Twa ynkapselingen lûke twa headers derôf, en in bûtenste tunnel dy't de MTU fan it paad al ferlege hat, lit binnen minder romte. De symptomen binne bekend: lytse fersiken slagje, grutte oerdrachten en TLS-handshakes stopje.

ip link set dev wg1 mtu 1280 is de groffe oplossing, en MSS beheine op 'e trochstjoerder is de krekter ien. De ferbining wer besykje is hielendal gjin oplossing.

5. Test de flater dy't do echt krije silst

Breek de bûtenste tunnel mei opset en sjoch wat der bart. In keatling dy't stil weromfalt op in direkte wei as de bûtenste hop stjert, is slimmer as gjin keatling, want it lekt krekt op it momint dat do mienden dat do bedutsen wiest. It winske gedrach is in kill switch dy't al it ferkear stopset. Skriuw it resultaat op, want do wolst it net midden yn in ynsidint werûntdekke.

Latenstyd en in twadde flaterpunt binne de fêste kosten. Twa hops betsjutte ek twa stipewachtrigen as der wat op in ûngeunstige oere stikken giet.