Tunelimi i ndarë për klientët e hotspotit nuk është përjashtim për aplikacion

Dy kërkesa që tingëllojnë njësoj nuk janë njësoj: «përjashto këtë aplikacion nga VPN» dhe «dërgo këtë destinacion të vetëm jashtë VPN për laptopin në hotspotin tim». E para ndryshon mënyrën se si një socket në telefon zgjedh një rrjet. E dyta duhet të ndryshojë një vendim përcilljeje për një paketë që erdhi nga një pajisje tjetër pasi telefoni e kishte pranuar tashmë atë. Ngatërrimi i të dyjave është arsyeja pse një klient hotspot përfundon me një përjashtim që ka vlejtur gjithmonë vetëm për shfletuesin e vetë telefonit.

Dy nënsisteme zotërojnë dy pyetjet

Android i mban të ndara rrjetëzimin e aplikacioneve dhe tethering-un. Socket-et e aplikacioneve caktohen në një rrjet nga stiva e lidhshmërisë, dhe një aplikacion VPN vendos cilat prej socket-eve të tij hyjnë në tunel. Paketat e përcjella nga një klient i lidhur trajtohen nga nënsistemi i tethering-ut, i cili i kërkon netd-it rrugë, rregulla politike dhe përkthim në ndërfaqen e poshtme.

Përjashtimi për aplikacion vlerësohet kur një aplikacion hap një socket. Një paketë e përcjellë nuk arrin kurrë në atë kontroll, sepse nuk ka origjinën nga një socket aplikacioni në këtë pajisje. Kjo është e gjithë arsyeja pse dy cilësimet nuk mund të zëvendësojnë njëri-tjetrin, dhe nuk është defekt në asnjërin prej tyre.

Çfarë ndryshon në të vërtetë përjashtimi për aplikacion

Ndërtuesi i VpnService mund të emërtojë paketat që mbeten jashtë tunelit me addDisallowedApplication, ose të emërtojë të vetmet paketa të lejuara brenda me addAllowedApplication. Këto aplikacione më pas hapin socket-e në rrjetin bazë, ndërsa VPN vazhdon të zotërojë rrugën e parazgjedhur për çdo gjë tjetër.

Shtrirja është e saktë: socket-et e vetë paketës, në këtë pajisje, për sa kohë tuneli është lart. Nuk thotë asgjë për trafikun e përcjellë, asgjë për një pajisje të dytë dhe asgjë për paketat që sistemi dërgon në emër të tethering-ut.

Nuk është as kontroll destinacioni. Përjashtimi i një shfletuesi përjashton çdo adresë që arrin ai shfletues, duke përfshirë atë që dëshironit ta mbanit brenda tunelit. Kur kërkesa emërton një destinacion në vend të një aplikacioni, përzgjedhësi i aplikacioneve është mjeti i gabuar nga vetë ndërtimi.

Si duket një paketë e tether-uar për telefonin

Paketa e klientit arrin në ndërfaqen e hotspotit me një adresë burimi private të caktuar nga telefoni, të themi 192.168.43.20, dhe një destinacion publik. Për ta përcjellë, telefoni ka nevojë për një rrugë drejt një lidhjeje të sipërme dhe një rregull përkthimi që përgjigjet të gjejnë rrugën e kthimit, sepse adresa private e klientit nuk ka kuptim në rrjetin celular.

Android e shpreh këtë me rregulla politike që zgjedhin një tabelë rrugëtimi, dhe netd rindërton tabelat dhe rregullat përkatëse kur ndryshojnë rrjetet dhe VPN-të. Një numër tabele, një prioritet rregulli ose një emër ndërfaqeje të kopjuara nga një postim forumi, ose nga i njëjti model në një version më të vjetër, nuk krijojnë pronësi të qëndrueshme. Ky rindërtim është edhe arsyeja pse një rregull i shkruar me dorë mund të punojë një orë dhe të ndalet pas rilidhjes tjetër.

Çfarë politike i nevojitet vërtet një përjashtimi hotspot

Shkruajeni vendimin si burim, destinacion dhe rrugë të synuar përpara se të prekni një rregull. Forma minimale për një destinacion të miratuar duket kështu:

Të dy drejtimet duhet të jenë të plota. Dega e drejtpërdrejtë ka nevojë për një rrugë të përdorshme përmes lidhjes së sipërme celulare që ndodh të jetë aktuale; dega VPN ka nevojë për rrugën e tunelit plus lejen për të përcjellë. Çdo përkthim burimi duhet të përputhet me daljen që zgjodhët, sepse NAT-i i aplikuar në një ndërfaqe tuneli paraqet adresën e tunelit dhe jo atë celulare, dhe atëherë rruga e kthimit nuk përputhet me rrugën e daljes.

Përgjigjet duhet të arrijnë te i njëjti klient i poshtëm përmes gjendjes së gjurmuar ose një rrugë të qartë, dhe një numërues paketash dalëse nuk provon asgjë nga kjo. Mbani edhe transportin e jashtëm të vetë VPN-së jashtë shtrirjes së përjashtimit, përndryshe paketat bartëse të tunelit trashëgojnë një politikë të shkruar për një kërkesë web të një klienti.

Një adresë e kapur nuk është destinacion

Një adresë e vetme IPv4 e lexuar nga një shfletues është një fotografi e çastit. Shërbimet e mëdha përgjigjen nga anycast ose nga një grup rrotullues adresash buzë, shumë janë me dy stiva, dhe një rrjedhë hyrjeje mund të prekë hoste autentikimi dhe telemetrie që faqja nuk i tregon kurrë. Një përjashtim i ndërtuar rreth adresës që patë rastësisht thyhet herën tjetër kur shërbimi ribalancon.

Përdorni adresat e dokumentuara të pronarit të shërbimit, ose një interval që ai publikon, dhe llogaritni të dyja familjet e adresave. Nëse kërkesa nuk mund të shprehet si një grup i qëndrueshëm, ka të ngjarë të jetë një pyetje politike për shërbimin dhe jo një truk rrugëtimi në një telefon.

Verifikoni nga ana e poshtme

Tre kontrolle, në këtë rend: shërbimi i zgjedhur nga laptopi, një destinacion i zakonshëm që duhet të mbetet brenda VPN, dhe një aplikacion telefoni që duhet të mbetet i paprekur. Më pas përsëriteni pas një rilidhjeje dhe pas një ndryshimi të lidhjes së sipërme, sepse atëherë rindërtohen tabelat e politikës.

Nëse implementimi i ndarjes së telefonit nuk mund ta mbajë atë kontratë përgjatë një rilidhjeje, zhvendosni politikën selektive në një ruter të poshtëm të mbështetur në vend që të grumbulloni rregulla root në aparat. Një ruter mund të shprehë përputhjen e burimit dhe destinacionit me një pronar të qëndrueshëm, dhe dokumentacioni i modulit të tethering-ut është referenca e duhur për atë që telefoni bën në të vërtetë.