Ĉenigi du VPN-ojn: kion ĝi kaŝas kaj kion ĝi kostas

Du nestitaj tuneloj ne igas vin anonimaj. Ili disdividas la observojn inter du provizantoj, do neniu el ili vidas vian hejman adreson kaj vian celon kune. Tio estas vera sed mallarĝa avantaĝo, kaj ĝi venas kun problemoj pri enkursigado, DNS kaj MTU, kiuj aperas la unuan fojon, kiam vi dependas de ĝi.

1. Decidu, por kio utilas la dua salto

Skribu la celon en unu frazo antaŭ ol vi agordi ion ajn. Se temas pri tio, ke via ISP ne povas vidi, kiujn retejojn vi vizitas, unu tunelo atingas tion. Se temas pri tio, ke neniu unuopa provizanto povas ligi vian adreson al via trafiko, du tion faras. Se temas pri tio, ke neniu povas identigi vin, neniu nombro da saltoj tien kondukas.

La ĉeno estas nur tiom forta kiom la protokoloj de la pli malforta provizanto kaj la kontoj, kiujn ambaŭ tenas. Pagoj, registriĝa retpoŝto kaj aplikaĵa telemetrio staras tute ekster la tunelo.

2. Faru la internan finpunkton atingebla tra la ekstera tunelo

La kutima malsukceso estas, ke la interna tunelo neniam establiĝas. Ekstera konekto kun plena tunelo posedas la defaŭltan vojon, do la provo de la interna kliento atingi sian propran finpunkton estas glutita de la ekstera tunelo kaj forĵetita aŭ buklita. La interna finpunkto bezonas eksplicitan vojon tra la ekstera interfaco, instalitan antaŭ ol la interna kliento startas. Alie la manpremo konkuras kun la vojo kaj malvenkas.

WireGuard montras la saman konflikton el la alia direkto. La AllowedIPs de ĉiu peer decidas, kiuj celoj eniras tiun tunelon, do interna interfaco postulanta ĉiun adreson ankaŭ postulas la eksteran finpunkton, se pli specifa vojo ne venkas. Interkovrantaj AllowedIPs sur du interfacoj estas agordo, en kiu unu flanko silente malvenkas.

Ĉenigo de ujoj faras la apartigon eksplicita kaj la kaptilon evidenta. Ujo kun propra nomspaco, propra defaŭlta vojo kaj kliento interne plusendadas tion, kion la gastiganto sendas al ĝi; la gastiganto mem ne ekuzas tiun vojon. Ŝaltu plusendadon, aldonu vojon por la tunelo de la ujo kaj direktu la servon al la adreso de la ujo.

3. Tenu DNS sur la sama vojo

DNS devas vojaĝi tien, kien vojaĝas la trafiko. Se la interna provizanto proponas solvilojn kaj la gastiganto ankoraŭ demandas la lokajn, tiuj serĉoj malkaŝas ĝuste la retejojn, kiujn la tunelo devis kaŝi. Kontrolu per kapto sur ĉiu tunela interfaco anstataŭ fidi la statpanelo de la kliento. Likado ĉi tie estas nevidebla dum normala retumado kaj evidenta en kapto.

Dividitaj DNS-desegnoj malfaciligas tion, ĉar peto pri loka nomo povas laŭleĝe aparteni ekster la tunelo. Skribu la esceptoliston intence anstataŭ malkovri ĝin laŭ tio, kiu solvilo hazarde respondis.

4. Agordu MTU antaŭ ol uzantoj malkovros ĝin por vi

MTU estas la alia antaŭvidebla viktimo. Du enkapsuligoj subtrahas du kapliniojn, kaj ekstera tunelo, kiu jam malaltigis la MTU de la vojo, lasas malpli da spaco interne. La simptomoj estas konataj: malgrandaj petoj sukcesas, grandaj transigoj kaj TLS-manpremoj haltas.

ip link set dev wg1 mtu 1280 estas la kruda solvo, kaj limigi MSS sur la plusendilo estas la pli pura. Reprovi la konekton tute ne estas solvo.

5. Testu la fiaskon, kiun vi vere ricevos

Intence rompu la eksteran tunelon kaj observu, kio okazas. Ĉeno, kiu silente refalas al rekta vojo, kiam la ekstera salto mortas, estas pli malbona ol neniu ĉeno, ĉar ĝi likas ĝuste en la momento, kiam vi kredis esti kovrita. Konduto cellinda estas mortigilo, kiu haltigas la tutan trafikon. Notu la rezulton, ĉar vi ne volos remalkovri ĝin meze de okazaĵo.

Latento kaj dua fiaskpunkto estas la konstantaj kostoj. Du saltoj ankaŭ signifas du subtenajn vicojn, kiam io rompiĝas en maloportuna horo.