Lietotnē vai galamērķī balstīts split tunneling: ko izvēlēties

Lietotnē un galamērķī balstīts split tunneling nav divi vienas un tās pašas darba iestatījumi. Viens jautā, kurš process sūta paketi; otrs jautā, kur šī pakete iet. Noteikums, kas veidots pirmajam jautājumam, klusi neizdodas, kad satiksme nāk no palīgprocesa, un noteikums otrajam neizdodas, kad resursdatora vārds tiek atrisināts uz adresi, kuru jūs nekad neesat norādījis. Izvēlieties prasībai atbilstošo objektu un pierādiet to ar divām testa paketēm: vienai ir jāizmanto tunelis, otrai – ne.

Divi noteikumi darbojas dažādos slāņos

Lietotnes noteikums tiek piemērots virs tīkla slāņa, pret identitāti, ko operētājsistēma piešķir sūtītājam. Android tas ir UID aiz paketes, un VPN pakalpojums katram UID izlemj, vai satiksme nonāk tunelī. Par galamērķi nekas netiek jautāts, tāpēc izvēlētā lietotne var sasniegt jebko, un neviena cita lietotne nevar sasniegt iekšējo tīklu.

Galamērķa noteikums tiek piemērots pašai paketei. Tuneļa saskarnei pieder prefiksu kopa, maršrutēšanas tabula sūta atbilstošo satiksmi tajā, un sūtošais process nav svarīgs. Tāpēc galamērķa noteikums aptver pakalpojumu, printeri vai pakešuzdevumu, ko neviens nav atcerējies iekļaut sarakstā, un tāpēc to nevar izteikt kā tieši šo programmu platformā, kuras klients nekad neskatās uz procesu.

Lietotnes noteikumi der mobilajiem klientiem un pārvaldītiem aģentiem

Android piedāvā izvēli tieši: VpnService.Builder.addAllowedApplication() un addDisallowedApplication() pieņem pakotņu nosaukumus un piemēro lēmumu katram UID, kā aprakstīts Android VPN izstrādātāja rokasgrāmatā. iOS ir ekvivalents, izmantojot katras lietotnes VPN noteikumus, kas balstīti uz pakotnes identifikatoriem un parasti tiek piegādāti ar MDM profilu, nevis ievadīti ar roku.

Darbvirsmas klienti ir vājā vieta. Lielākā daļa Windows un macOS VPN klientu maršrutē pēc galamērķa un vispār nepiedāvā izvēlni pēc procesa, jo tuneļa draiveris redz paketes, nevis procesus. Ja jūsu plāns ir atkarīgs no vienas lietotnes tunelēšanas klēpjdatorā, pārbaudiet klienta faktiskās iespējas pirms projektēšanas ap to; iespējams, jūs izvēlaties starp galamērķu sarakstu un otru mašīnu.

Sekas, ko cilvēki izlaiž: šajās platformās jūs nevarat atdarināt lietotnes noteikumu ar maršrutiem. Pievienojot resursdatora maršrutu lietotnes serverim, visu satiksme tiek tunelēta uz šo serveri, ieskaitot pārlūku un atjaunināšanas programmu.

Galamērķa noteikumi der apakštīklu sarakstiem un vietņu sasniedzamībai

WireGuard padara modeli skaidru. AllowedIPs ir šifrēšanas atslēgas maršrutēšana: iekšējā pakete, kuras galamērķis iekrīt partnera sarakstā, tiek šifrēta šim partnerim, un viss pārējais iziet nešifrēts pa parasto ceļu. Nav procesa, ko nosaukt, un nav neskaidrības par to, kas ir iekļauts.

OpenVPN nonāk tajā pašā vietā, izmantojot uzspiesto maršrutēšanas tabulu. route-nopull neļauj serverim diktēt maršrutus, pēc tam klienta puses route 10.20.0.0 255.255.0.0 vpn_gateway aptver tieši biroja prefiksu. IPv6 ir atsevišķs paziņojums katrā no šiem klientiem, un tā aizmiršana ir visizplatītākais veids, kā noplūst ap pareizi izskatāmu IPv4 sadalījumu.

Resursdatora vārds nav maršruts. Ja profils piedāvā domēna lauku, uztveriet to kā vārdu, ko klients atrisina vienu reizi, nevis kā pastāvīgu adrešu diapazonu; satura piegādes tīkli un slodzes līdzsvarotāji rīt dos citas adreses.

Kur lūzt abi modeļi: palīgi, koplietoti pakalpojumi, atrisinātāji

Palīgprocesi salauž lietotnes noteikumus tā, ka tas izskatās pēc servera kļūmes. Pārlūka atjaunināšanas programma, avārijas pārskats, sinhronizācijas pakalpojums, kas darbojas kā SYSTEM, un citā pakotnē iegultais WebView ir atsevišķas identitātes, tāpēc pārlūka tunelēšana var atstāt īsto pieprasījumu ārpus tuneļa. Pretējais ir tikpat mulsinošs: izslēgtā lietotne, kas izsauc koplietoto bibliotēku tunelētā procesa iekšienē, joprojām sūta savu satiksmi pa tuneli.

Galamērķa noteikumi lūst uz koplietotiem pakalpojumiem un uz vārdiem. Failu koplietojumi, printeri, iekšējais DNS un licences serveris visi dzīvo adresēs, tāpēc vienas lietotnes tunelis dod pārlūkam piekļuvi, kamēr piesaistītais disks paliek miris. Šī pārklājuma atšķirība nav kļūda nevienā modelī, taču tā ir iemesls, kāpēc vienas lietotnes tunelis tik bieži rada situāciju, ka VPN darbojas, bet koplietojums ir pazudis.

Atrisinātāji šķērso abus. Ja klients iestata iekšējos DNS serverus, bet operētājsistēma izmanto DNS over HTTPS uz publisku atrisinātāju, atbilde nāk no ārpuses tuneļa un galamērķa noteikums var nekad nesakrist. Pārbaudiet, kurš atrisinātājs faktiski atbildēja, pirms secināt, ka noteikums ir nepareizs, un klienta pusē apstipriniet, vai tas vispār instalēja tuneļa atrisinātāju. Sadalījums, kas atstāj DNS ārpus tuneļa, maršrutēšanas tabulā izskatās nevainojami un tomēr neizdodas katrā iekšējā vārdā.

Darbības plāns: izvēlēties, piemērot, pārbaudīt

Sāciet ar prasību, nevis izvēlni. Ja mērķis ir tikai šī lietotne drīkst izmantot tuneli, jums vajag lietotnes noteikumus un platformu, kas tos atbalsta. Ja mērķis ir šie tīkli ir sasniedzami caur tuneli, jums vajag prefiksus. Ja atbilde ir abi, ieviesiet tos kā divas atsevišķas vadīklas un pierakstiet, kura par kuru kļūmi atbild.

Piemērojiet šaurāko formu, ko varat izteikt, pēc tam pārbaudiet, jautājot maršrutēšanas tabulai, nevis klienta statusa ikonai:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Pirmās divas rindas nosauc saskarni, ko izmantotu īsts galamērķis; wg show izdrukā konfigurēto prefiksu sarakstu; Windows Find-NetRoute atbild uz to pašu jautājumu, uz ko atbildēs steks, kad pakete tiks nosūtīta. Ja saskarne ir tunelis, noteikums sakrita.

Pēc tam pārbaudiet otru paketi, kas būtu jāizslēdz, no citas lietotnes, uz to pašu galamērķi. Biļetē ierakstiet klienta versiju, noteikuma veidu, prefiksu vai pakešu sarakstu un divus novērotos rezultātus. Tieši šis rezultātu pāris pasaka nākamajam inženierim, vai politika ir nepareizi konfigurēta, vai satiksme tai nekad nav piederējusi.