Dvije VPN aplikacije istovremeno: koji kill switch zapravo vrijedi?

Dva VPN klijenta mogu raditi jedan uz drugi, ali njihovi se kill switchevi ne stapaju u jednu politiku. Svaki klijent instalira pravila za svoj tunel i nijedan ne zna da drugi postoji. Naišao sam na to s poslovnim klijentom spojenim prvim: druga aplikacija nije mogla dovršiti rukovanje, deset minuta je stajala na „Connecting“, a prvi je tunel tiho nosio sve. Hoće li druga aplikacija biti zaštićena, ovisi o tri uvjeta, a ne o tome pokazuju li obje ikone Povezano.

Na što je kill switch zapravo ograničen

Ništa u operacijskom sustavu nema jedinstvenu zastavicu kill switcha. Klijent koji je reklamira instalira skup pravila: odbaci sve što ne izlazi kroz moj tunel i često fail closed kad tunel nestane. Na Linuxu je to obično nftables ili iptables lanac, na Windowsu skup filtara Windows Filtering Platform, na Androidu i iOS-u vlastito usmjeravanje tunelske usluge plus sistemska postavka koja blokira veze bez VPN-a. Vodič za VPN na Androidu opisuje taj model usluge ako želite pogled s platforme.

Opseg je dio koji je važan. Pravilo poput „dopusti samo pakete na izlaznom sučelju wg0“ ne zanima postoji li drugi tunel. Ako drugi klijent podigne wg1, pravila prvog klijenta tretiraju te pakete kao običan promet: obično odbačene, ponekad dopuštene. U svakom slučaju odlučuje prvi klijent i nema pojma da druga aplikacija čeka.

Tri uvjeta koja odlučuju koga će pokriti

Ne trebate nabrajati svaku kombinaciju. Tri pitanja to rješavaju u nekoliko minuta.

1. Dopušta li platforma uopće drugi tunel? Većina Android telefona i iPhonea prihvaća samo jednu aktivnu VPN uslugu po korisničkom profilu, pa druga aplikacija nikad nema tunel i nikad ništa ne provodi. Dobivate jednu politiku — od aplikacije koja je osvojila mjesto.
2. Koji proces posjeduje zadanu rutu? Windows, macOS i Linux mirno nose dva tunela. Zadana ruta pripada klijentu koji ju je postavio posljednji ili s boljom metrikom, a drugi je klijent spojen ali neaktivan. Na Linuxu način zadane rute u wg-quicku koristi usmjeravanje po politici s privatnom tablicom i fwmark pravilom, pa drugi wg-quick tunel dodaje konkurentsko pravilo umjesto da zamijeni prvo.
3. Može li drugi klijent doći do vlastitog poslužitelja? Ako je prvi kill switch po načelu zadanog odbijanja, vanjska krajnja točka druge aplikacije samo je još jedno odbačeno odredište. Tiho pokušava ponovno i nikad ne prijavi pogrešku.

Kratka verzija, za teme podrške:

Dva od tih redaka izgledaju identično s ikone u sistemskoj traci, zato je ikona ovdje najgori dostupni dokaz.

Što prvo zakaže i kako to izgleda

Klijent zaglavljen na „Connecting“ dok je drugi zdrav gotovo je uvijek glad za krajnjom točkom: aktivni kill switch odbacuje rukovanje drugog klijenta prema njegovu vlastitom poslužitelju. Potvrdite to jeftino pauzirajući pravila blokiranja prvog klijenta na jedan pokušaj. Ako se drugi spoji odmah, pitanje je odgovoreno.

DNS je drugi otkaz. Klijenti postavljaju konfiguraciju razrješivača za svoje sučelje, a neki jednostavno prepišu globalni popis. Uz oba aktivna tunela, upiti mogu izlaziti kroz jednu stranu dok razrješivač pripada drugoj. Odspojite bilo koju aplikaciju i preživjela zadržava nedostupan poslužitelj imena: stranice zapnu na minutu pa se ponovno razriješe, dok VPN i dalje pokazuje povezano.

Treći je treptanje ruta. Ponovna spajanja preuređuju zadanu rutu, a kill switch vezan uz sučelje ne slijedi ju. Promet koji je prije trenutka bio u tunelu sada odgovara pravilu odbacivanja, što se na strani korisnika čita kao VPN koji nasumično prestaje raditi.

Provjerite koja je politika doista na snazi

Radite to s bezopasnim prometom, ne s nečim što bi vam nedostajalo.

Na Linuxu pitajte jezgru tko pobjeđuje i na što se veže vatrozid. ip -4 route show default imenuje tunel koji posjeduje izlaz. ip rule show pokazuje je li usmjeravanje po politici u igri. sudo nft list ruleset | grep -n oifname pokazuje jesu li odbacivanja vezana uz naziv sučelja, oznaku ili cijeli izlazni lanac.

Na Windowsu ista priča živi u metrici rute i popisu filtara: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric i Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Na macOS-u netstat -rn -f inet | head -5 i scutil --dns | head -20.

Zatim napravite korak koji ljudi preskaču: namjerno zaustavite tunel i potvrdite da promet koji očekujete da će pasti doista pada. Povezana ikona je stanje sučelja, ne provedba.

Kada su dva klijenta pogrešan dizajn

Ako je jedini zahtjev iza druge aplikacije više zaštite, uklonite ju. Dvije politike blokiranja koje djeluju jedna na drugu manje su predvidive od jedne, a svako ponovno spajanje prilika je da završite u stanju koje nijedan dobavljač ne testira.

Ako vam doista treba lančano povezivanje, primjerice korporativni pristupnik preko komercijalnog skoka, odaberite dizajn s jednom točkom provedbe. To obično znači usmjerivač ili jedan klijent koji podržava lanac, a ne dvije desktop aplikacije koje se natječu za istu zadanu rutu. Na upravljanom uređaju držite se odobrenog klijenta, a sve ostalo tretirajte kao izvan opsega, što god ono pokazivalo u sistemskoj traci.

Popis za provjeru prije nego zadržite oba

Prođite popis redom; prva stavka koja padne je ona koju treba popraviti.

• Potvrdite da točno jedan klijent posjeduje zadanu rutu i razrješivač.
• Ako želite da drugi klijent radi, izričito dopustite krajnju točku njegova poslužitelja i ponovno provjerite nakon svakog ažuriranja klijenta.
• Zapišite očekivani ishod kad padne bilo koji tunel i testirajte upravo taj slučaj.
• Provjerite put otkaza nakon restarta, kad je redoslijed pokretanja drukčiji.
• Na upravljanom profilu zaustavite se i pitajte vlasnika prije nego bilo što dodate.

Ako treći korak padne, iskren odgovor je da vam politiku daje samo jedan klijent. Odlučite kojemu vjerujete i pustite drugi.