Pse trafiku i korrigjimit me valë nuk është provë e një rrjedhjeje VPN

Aktivizuat korrigjimin me valë, lidhët një laptop, dhe sesioni vazhdoi të funksiononte ndërsa VPN-ja ishte aktive. Kjo duket sikur diçka rrëshqiti përtej tunelit. Pothuajse me siguri jo. Një sesion korrigjimi dhe kërkesa e një aplikacioni drejt një faqe web janë marrëdhënie të ndryshme rrjeti, dhe vetëm njëra prej tyre duhet të kalojë tunelin.

Këtë lexim të gabuar e kam hasur dy herë: një herë me telefonin dhe laptopin në të njëjtin Wi-Fi, dhe një herë pas një rindezjeje kur çiftimi mbijetoi. Në të dyja rastet VPN-ja bënte saktësisht atë për të cilën ishte konfiguruar.

Emërtoni vëzhgimin para se të emërtoni gabimin

Tre ngjarje mund të paraprijnë një pohim rrjedhjeje, dhe ato nuk janë të këmbyeshme. Një mjet mund të zbulojë një shërbim, pajisja mund të miratojë një stacion pune, ose një sesion i autorizuar mund të transportojë vërtet komanda dhe bajt. Shkruani cilën patë, sepse secila provon më pak nga sa supozojnë njerëzit.

Zbulimi është zakonisht mDNS ose një skanim portesh. Çiftimi është një vendim regjistrimi i marrë në telefon, i konfirmuar me një kod që përdoruesi shkruan. Një sesion i gjallë do të thotë që trafiku lëvizi midis dy pikave fundore të çiftuara. Asnjë prej këtyre nuk përshkruan ku shkon kërkesa HTTPS e një aplikacioni.

Mbani destinacionin, ndërfaqen, familjen e adresave, vulën kohore dhe profilin e përdoruesit të lidhura me ngjarjen. Pa këto detaje vëzhgimi nuk mund të krahasohet me politikën e synuar të rrjetit lokal, ose me versionin e VPN-së që po ekzekutohej atëherë.

Pse dy rrugët nuk takohen kurrë

Korrigjimi me valë është një lidhje hyrëse drejt pajisjes. adbd dëgjon në një port të lidhur me ndërfaqen Wi-Fi, dhe stacioni i punës lidhet me të pas çiftimit. Drejtimi ka rëndësi: laptopi juaj arrin në telefon, jo e kundërta. Kjo është e kundërta e një rrjedhjeje dalëse.

Trafiku i internetit i një aplikacioni del përmes ndërfaqes së tunelit që instalon VpnService, i përputhur sipas UID dhe rregullave të rrugëzimit. adbd është një demon sistemi që ekzekutohet si përdorues shell, jo një aplikacion brenda atij grupi rrugëzimi. Qëndron në lidhjen bazë Wi-Fi edhe kur çdo aplikacion është i fiksuar në tunel.

Modaliteti i bllokimit imponon tunelin për aplikacionet e mbuluara. Nuk e kthen një soket dëgjues në rrugë daljeje.

Kjo është arsyeja pse një sesion ADB funksional dhe një çelës ndalimi funksional bashkëjetojnë pa kundërshtim. Për të provuar një rrjedhje, duhet të vëzhgoni drejtimin që duhet të bllokohet.

Si duket në të vërtetë një provë daljeje

Testoni aplikacionin e mbuluar, jo kanalin e korrigjimit. Vendosni qëllimisht gjendjen e dështimit, më pas bëni një kërkesë të re dhe regjistroni çfarë ndodhi.

1. Konfirmoni që VPN-ja është e vetmja rrugë: aktivizoni VPN gjithmonë aktive me bllokimin e lidhjeve pa VPN.
2. Ndaloni VPN-në në mënyrën e mbështetur dhe konfirmoni që aplikacioni raporton mungesë lidhjeje.
3. Dërgoni një kërkesë të padëmshme nga ai aplikacion dhe vini re nëse dështon apo ka sukses.
4. Përsëriteni me korrigjimin me valë të aktivizuar, pastaj të çaktivizuar, që variabli të izolohet.

Një kërkesë e bllokuar në ato kushte është provë. Një sesion ADB i suksesshëm nuk është, dhe as një ping i vetëm nga një aplikacion terminali.

Nëse kërkesa ka sukses ndërsa bllokimi është aktiv, regjistroni UID-në e aplikacionit dhe lejen e tij VPN, rrjetin aktiv dhe versionin e klientit. Ai kombinim është një gjetje e vërtetë.

Çiftimi mbijeton më shumë se sesioni

Çiftimi është gjendje e përhershme, jo një shtrëngim duarsh që harrohet pas testit me kabllo. Dokumentacioni i korrigjimit të Android përshkruan rrjedhën e punës me valë dhe vëren se marrëdhënia zgjat derisa të harrohet në mënyrë të shprehur ose derisa autorizimet të revokohen.

Kontrolloni çfarë është ende e autorizuar përpara se të fajësoni tunelin. Hapni Korrigjimin me valë, shikoni Pajisjet e çiftuara dhe harroni gjithçka që nuk e njihni më. Ekzekutoni adb devices nga stacioni i punës për të parë cilat hyrje përgjigjen ende, dhe adb disconnect për të hequr një të vjetruar. Çaktivizimi i korrigjimit me valë mbyll plotësisht portin dëgjues.

Në një rrjet të përbashkët ose jo të besueshëm, lëreni të çaktivizuar. Një autorizim i përhershëm në një rrjet që nuk e kontrolloni është problem më i madh se një anashkalim hipotetik i TUN.

Përpara se të raportoni atë gabim

Një raport i dobishëm emërton kufirin e saktë që dështoi. Përfshini modelin e pajisjes dhe versionin e Android, klientin VPN dhe versionin, nëse bllokimi ishte aktiv, paketën e aplikacionit dhe UID-në, dhe rrjetin në të cilin ishte telefoni. Shtoni komandën ose kërkesën që prodhoi vëzhgimin, plus kohën kur ndodhi. Pa këto, askush nuk mund të riprodhojë kufirin që thoni se është thyer.

Mos çaktivizoni zbatimin dhe mos ekspozoni korrigjimin në një rrjet jo të besueshëm për ta bërë testin të duket më dramatik. Kjo ndryshon sistemin që po matni dhe lë prova që askush nuk mund t'i përsëritë.

Nëse prova juaj e vetme është se ADB u lidh ndërsa VPN-ja ishte aktive, keni matur rrugën e gabuar. Ekzekutoni përsëri së pari testin në nivel aplikacioni; përgjigjja zakonisht vjen atje.