Divas VPN lietotnes vienlaikus: kurš kill switch patiešām darbojas?

Divi VPN klienti var darboties līdzās, bet to kill switch neapvienojas vienā politikā. Katrs klients instalē noteikumus savam tunelim, un neviens nezina, ka otrs pastāv. Es ar to saskāros, kad pirmais bija pieslēgts darba klients: otrā lietotne nevarēja pabeigt roku sasveicināšanu, desmit minūtes karājās uz „Connecting“, un pirmais tunelis klusi nesa visu. Vai otrā lietotne tiks aizsargāta, ir atkarīgs no trim nosacījumiem, nevis no tā, vai abas ikonas rāda Pievienots.

Uz ko kill switch patiešām attiecas

Nekas operētājsistēmā nav viena kill switch karodziņa. Klients, kas tādu reklamē, instalē noteikumu kopumu: atmet visu, kas neiziet caur manu tuneli, un bieži fail closed, kad tunelis pazūd. Linux tas parasti ir nftables vai iptables ķēde, Windows — Windows Filtering Platform filtru kopa, Android un iOS — paša tuneļa pakalpojuma maršrutēšana plus sistēmas iestatījums, kas bloķē savienojumus bez VPN. Android VPN rokasgrāmata apraksta šo pakalpojuma modeli, ja vēlaties platformas skatījumu.

Apjoms ir tā daļa, kas ir svarīga. Noteikums „atļaut tikai paketes izejas saskarnē wg0“ neinteresējas, vai pastāv otrs tunelis. Ja cits klients paceļ wg1, pirmā klienta noteikumi šīs paketes uzskata par parastu satiksmi: parasti atmet, dažkārt atļauj. Jebkurā gadījumā izlemj pirmais klients, un tam nav ne jausmas, ka otrā lietotne gaida.

Trīs nosacījumi, kas izšķir, kas tiks segts

Nav jāuzskaita katra kombinācija. Trīs jautājumi to atrisina dažu minūšu laikā.

1. Vai platforma vispār pieļauj otru tuneli? Lielākā daļa Android tālruņu un iPhone pieņem tikai vienu aktīvu VPN pakalpojumu uz lietotāja profilu, tāpēc otrajai lietotnei nekad nav tuneļa un tā neko neievieš. Jūs saņemat vienu politiku — no lietotnes, kas ieguva vietu.
2. Kuram procesam pieder noklusējuma maršruts? Windows, macOS un Linux bez problēmām nes divus tuneļus. Noklusējuma maršruts pieder klientam, kas to iestatīja pēdējais vai ar labāku metriku, un otrs klients ir pievienots, bet dīkstāvē. Linux wg-quick noklusējuma maršruta režīms izmanto politikas maršrutēšanu ar privātu tabulu un fwmark noteikumu, tāpēc otrs wg-quick tunelis pievieno konkurējošu noteikumu, nevis aizstāj pirmo.
3. Vai otrais klients sasniedz savu serveri? Ja pirmais kill switch ir noklusējuma aizliegums, otrās lietotnes ārējais galapunkts ir tikai vēl viens atmests galamērķis. Tas klusi mēģina vēlreiz un nekad neziņo par kļūdu.

Īsā versija atbalsta pavedieniem:

Divi no šiem rindām izskatās identiski no ikonas sistēmas teknē, tāpēc ikona šeit ir sliktākais pieejamais pierādījums.

Kas sabojājas pirmais un kā tas izskatās

Klients, kas iesprūdis uz „Connecting“, kamēr otrs ir vesels, gandrīz vienmēr nozīmē galapunkta badu: aktīvais kill switch atmet otrā klienta roku sasveicināšanu pret tā pašu serveri. Pārbaudiet to lēti, uz vienu mēģinājumu apturot pirmā klienta bloķēšanas noteikumus. Ja otrais pieslēdzas uzreiz, jautājums ir atbildēts.

DNS ir otrs bojājums. Klienti iestata atrisinātāja konfigurāciju savai saskarnei, un daži vienkārši pārraksta globālo sarakstu. Ar abiem tuneļiem augšā vaicājumi var iziet pa vienu pusi, kamēr atrisinātājs pieder otrai. Atvienojiet jebkuru lietotni, un izdzīvojusī paliek ar nesasniedzamu nosaukumu serveri: lapas iestrēgst uz minūti un pēc tam atkal atrisinās, kamēr VPN joprojām rāda pievienots.

Trešais ir maršrutu plīvošana. Atkārtoti pieslēgumi pārkārto noklusējuma maršrutu, un pie saskarnes piesaistītais kill switch tam neseko. Satiksme, kas pirms brīža bija tunelī, tagad atbilst atmešanas noteikumam, un lietotāja pusē tas lasās kā VPN, kas nejauši pārstāj darboties.

Pārbaudiet, kura politika patiešām ir spēkā

Dariet to ar nekaitīgu satiksmi, nevis ar to, pēc kā jums pietrūktu.

Linux jautājiet kodolam, kas uzvar un kam ugunsmūris piesaistās. ip -4 route show default nosauc tuneli, kuram pieder izeja. ip rule show parāda, vai spēlē ir politikas maršrutēšana. sudo nft list ruleset | grep -n oifname parāda, vai atmešanas ir piesaistītas saskarnes nosaukumam, atzīmei vai visai izejas ķēdei.

Windows tā pati stāsta dzīvo maršruta metrikā un filtru sarakstā: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric un Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS — netstat -rn -f inet | head -5 un scutil --dns | head -20.

Pēc tam izdariet soli, ko cilvēki izlaiž: apzināti apturiet tuneli un apstipriniet, ka satiksme, kurai jācieš neveiksme, patiešām cieš neveiksmi. Pievienota ikona ir saskarnes stāvoklis, nevis izpilde.

Kad divi klienti ir nepareizs dizains

Ja vienīgā prasība aiz otrās lietotnes ir vairāk aizsardzības, noņemiet to. Divas savstarpēji iedarbojošās bloķēšanas politikas ir mazāk paredzamas nekā viena, un katrs atkārtotais pieslēgums ir iespēja nonākt stāvoklī, ko neviens piegādātājs netesta.

Ja jums patiešām vajag ķēdēšanu, piemēram, uzņēmuma vārteju, kas sasniegta caur komerciālu lēcienu, izvēlieties dizainu ar vienu izpildes punktu. Tas parasti nozīmē maršrutētāju vai vienu klientu, kas atbalsta ķēdi, nevis divas darbvirsmas lietotnes, kas sacenšas par to pašu noklusējuma maršrutu. Pārvaldītā ierīcē turiet apstiprināto klientu un visu pārējo uzskatiet par ārpus tvēruma, lai ko tas rādītu teknē.

Kontrolsaraksts pirms abu paturēšanas

Izejiet sarakstu pēc kārtas; pirmais neizdevušais punkts ir tas, kas jālabo.

• Apstipriniet, ka tieši viens klients pārvalda noklusējuma maršrutu un atrisinātāju.
• Ja vēlaties otru klientu, skaidri atļaujiet tā servera galapunktu un pārbaudiet vēlreiz pēc katras klienta atjaunināšanas.
• Pierakstiet gaidāmo iznākumu, kad krīt jebkurš tunelis, un pārbaudiet tieši šo gadījumu.
• Pārbaudiet atteices ceļu pēc restartēšanas, kad palaišanas secība ir citāda.
• Pārvaldītā profilā apstājieties un pirms kaut kā pievienošanas pajautājiet īpašniekam.

Ja trešais solis neizdodas, godīgā atbilde ir tāda, ka politiku dod tikai viens klients. Izlemiet, kuram uzticaties, un laidiet otru prom.