Du VPN-aplikoj samtempe: kiu kill switch vere validas?

Du VPN-klientoj povas funkcii unu apud la alia, sed iliaj kill switch ne fandiĝas en unu politikon. Ĉiu kliento instalas regulojn por sia propra tunelo, kaj neniu scias, ke la alia ekzistas. Mi trafis tion kun laborkliento konektita unue: la dua aplikaĵo ne povis fini sian manpremon, restis ĉe „Connecting“ dum dek minutoj, kaj la unua tunelo silentete portis ĉion. Ĉu la dua aplikaĵo estos protektata dependas de tri kondiĉoj, ne de tio, ĉu ambaŭ ikonoj diras Konektita.

Al kio kill switch vere limiĝas

Nenio en la operaciumo havas unu solan kill switch-flagon. Kliento, kiu reklamas tian, instalas regularon: forĵetu ĉion, kio ne eliras tra mia tunelo, kaj ofte fail closed kiam la tunelo malaperas. En Linux tio kutime estas nftables- aŭ iptables-ĉeno, en Windows aro da Windows Filtering Platform-filtriloj, en Android kaj iOS la propra enkursigo de la tunela servo plus la sistema agordo, kiu blokas konektojn sen VPN. La Android VPN-gvidilo priskribas tiun servomodelon, se vi volas la platforman vidpunkton.

La amplekso estas la parto, kiu gravas. Regulo kiel „permesu nur pakaĵojn sur la elira interfaco wg0“ ne zorgas, ĉu ekzistas dua tunelo. Se alia kliento levas wg1, la reguloj de la unua kliento traktas tiujn pakaĵojn kiel ordinaran trafikon: kutime forĵetitaj, foje permesitaj. Ĉiuokaze decidas la unua kliento, kaj ĝi havas neniun ideon, ke dua aplikaĵo atendas.

Tri kondiĉoj, kiuj decidas, kiu estos kovrita

Vi ne devas listigi ĉiun kombinaĵon. Tri demandoj solvas tion en kelkaj minutoj.

1. Ĉu la platformo entute permesas duan tunelon? Plej multaj Android-telefonoj kaj iPhone-oj akceptas nur unu aktivan VPN-servon por uzantprofilo, do la dua aplikaĵo neniam havas tunelon kaj neniam efektivigas ion. Vi ricevas unu politikon — de la aplikaĵo, kiu gajnis la lokon.
2. Kiu procezo posedas la defaŭltan itineron? Windows, macOS kaj Linux portas du tunelojn senprobleme. La defaŭlta itinero apartenas al la kliento, kiu agordis ĝin laste aŭ kun la plej bona metriko, kaj la alia kliento estas konektita sed senokupa. En Linux la defaŭlta itinera reĝimo de wg-quick uzas politikan enkursigon kun privata tabelo kaj fwmark-regulo, do dua wg-quick-tunelo aldonas konkurantan regulon anstataŭ anstataŭigi la unuan.
3. Ĉu la dua kliento povas atingi sian propran servilon? Se la unua kill switch estas defaŭlte malpermesa, la ekstera finpunkto de la dua aplikaĵo estas nur plia forĵetita celo. Ĝi reprovas silente kaj neniam raportas eraron.

La mallonga versio, por subtenaj fadenoj:

Du el tiuj vicoj aspektas identaj de la ikono en la suŝiopleto, kaj tial la ikono estas la plej malbona havebla pruvo ĉi tie.

Kio unue malsukcesas, kaj kiel tio aspektas

Kliento blokita ĉe „Connecting“ dum la alia estas sana preskaŭ ĉiam signifas finpunktan malsaton: la aktiva kill switch forĵetas la manpremon de la dua kliento al ĝia propra servilo. Konfirmu tion malmultekoste, paŭzigante la blokajn regulojn de la unua kliento por unu provo. Se la dua konektiĝas tuj, la demando estas respondita.

DNS estas la dua paneo. Klientoj agordas la solvilon por sia propra interfaco, kaj iuj simple anstataŭskribas la tutmondan liston. Kun ambaŭ tuneloj supren, demandoj povas eliri tra unu flanko dum la solvilo apartenas al la alia. Malkonektu iun ajn aplikaĵon kaj la pluvivanto tenas neatingeblan nomservilon: paĝoj haltas dum minuto kaj poste denove solviĝas, dum la VPN ankoraŭ montras konektitan.

La tria estas itinera flirtado. Rekonektoj reordigas la defaŭltan itineron, kaj interfac-ligita kill switch ne sekvas ĝin. Trafiko, kiu antaŭ momento estis en la tunelo, nun kongruas kun forĵeta regulo, kio ĉe la uzanto legiĝas kiel VPN, kiu hazarde ĉesas funkcii.

Kontrolu, kiu politiko efektive validas

Faru tion kun sendanĝera trafiko, ne kun io, kion vi mankus.

En Linux demandu la kernon, kiu venkas kaj al kio la fajroŝirmilo ligiĝas. ip -4 route show default nomas la tunelon, kiu posedas la eliron. ip rule show montras, ĉu politika enkursigo estas en la ludo. sudo nft list ruleset | grep -n oifname montras, ĉu forĵetoj estas ligitaj al interfaca nomo, marko aŭ la tuta elira ĉeno.

En Windows la sama rakonto vivas en la itinera metriko kaj la filtrila listo: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric kaj Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". En macOS netstat -rn -f inet | head -5 kaj scutil --dns | head -20.

Poste faru la paŝon, kiun homoj saltas: haltigu la tunelon intence kaj konfirmu, ke la trafiko, kiun vi atendas malsukcesi, vere malsukcesas. Konektita ikono estas interfaca stato, ne plenumo.

Kiam du klientoj estas la malĝusta dezajno

Se la sola postulo malantaŭ la dua aplikaĵo estas pli da protekto, forigu ĝin. Du interagantaj blokpolitikoj estas malpli antaŭvideblaj ol unu, kaj ĉiu rekonekto estas ŝanco fini en stato, kiun neniu provizanto testas.

Se vi vere bezonas ĉenadon, ekzemple firmaan enirejon atingitan per komerca salto, elektu dezajnon kun unu plenum-punkto. Tio kutime signifas enkursigilon aŭ unu klienton, kiu subtenas la ĉenon, ne du labortablajn aplikaĵojn konkurantajn pri la sama defaŭlta itinero. Sur administrata aparato tenu la sankciitan klienton kaj traktu ĉion alian kiel ekster la amplekso, kion ajn ĝi montras en la suŝiopleto.

Kontrola listo antaŭ ol teni ambaŭ

Trairu la liston laŭ ordo; la unua malsukcesa punkto estas tiu, kiun oni riparu.

• Konfirmu, ke ekzakte unu kliento posedas la defaŭltan itineron kaj la solvilon.
• Se vi volas la duan klienton supren, permesu eksplicite la finpunkton de ĝia servilo kaj rekontrolu post ĉiu klienta ĝisdatigo.
• Notu la atendatan rezulton, kiam iu ajn tunelo falas, kaj testu ĝuste tiun kazon.
• Kontrolu la fiaskovojon post restarto, kiam la starta ordo estas alia.
• Sur administrata profilo haltu kaj demandu la posedanton antaŭ ol aldoni ion.

Se la tria paŝo malsukcesas, la honesta respondo estas, ke nur unu kliento donas al vi politikon. Decidu, kiun vi fidas, kaj lasu la alian iri.