Android always-on VPN: si zgjidhet së pari emri i pikës fundore

Telefoni riniset, always-on është aktiv, «blloko lidhjet pa VPN» është ndezur, dhe tuneli nuk ngrihet kurrë. Asgjë nuk është konfiguruar gabim: bllokimi bën punën e vet, dhe përpjekja e vetë klientit për të arritur pikën e vet fundore i nënshtrohet gjithashtu. Emri i pikës fundore duhet të zgjidhet përpara se tuneli të ekzistojë, nga një klient që lejohet të flasë me rrjetin ndërsa të gjitha aplikacionet e tjera nuk lejohen. Kuptimi i asaj se cili komponent e bën këtë, dhe në çfarë radhe, e kthen këtë mister në një pyetje konfigurimi.

Çfarë kërkon në të vërtetë ndërtuesi i VPN

Një aplikacion VPN për Android nuk i jep platformës adresën e një serveri. Ai ndërton një ndërfaqe lokale: adresa dhe rrugë për tunelin, zgjidhësit që aplikacionet duhet të përdorin brenda tij, dhe pastaj establish() kthen një përshkrues skedari që aplikacioni e lexon dhe e shkruan si paketa IP të papërpunuara. Pika fundore e largët nuk shfaqet fare në atë ndërtues.

Ky është fakti strukturor kyç. Platforma krijon një ndërfaqe tun dhe zbaton politikën mbi të; aplikacioni implementon transportin në hapësirën e përdoruesit, që do të thotë se vetë aplikacioni zgjidh emrin e pikës së vet fundore dhe hap lidhjen e kriptuar. Një pikë fundore në formën e emrit të hostit është pra e mundur — jo sepse platforma mbështet emrat, por sepse platforma nuk e sheh kurrë pikën fundore.

Një fushë e ndërtuesit megjithatë pranon adresa: serverët DNS. Ato duhet të jenë adresa numerike zgjidhësish, zakonisht ato që operatori dëshiron të pyesë përmes tunelit. Ajo fushë përshkruan se ku aplikacionet dërgojnë pyetjet pasi tuneli është ngritur. Nuk thotë asgjë për mënyrën se si klienti e gjen pikën fundore, dhe trajtimi i të dyjave si i njëjti rregullim është vendi ku fillon konfuzioni.

Dy pyetje DNS, jo një

Pyetja e parë është: ku dërgojnë aplikacionet pyetjet kur tuneli është ngritur? Përgjigja është një adresë zgjidhësi brenda tunelit, e arritshme përmes ndërfaqes tun, dhe numerike nga ndërtimi.

Pyetja e dytë është: si e gjen klienti pikën e vet fundore përpara se ai tunel të ekzistojë? Ai kërkim ndodh jashtë tunelit, në rrjetin bazë, në procesin e klientit. Mund të përdorë një emër, dhe duhet të përdorë një zgjidhës që pajisja arrin pa VPN.

Tre faza, tre simptoma të ndryshme. Një mesazh i vetëm gabimi që thotë «nuk mund të lidhet» i bashkon ato, dhe për këtë arsye njerëzit fillojnë të redaktojnë fushën e serverit DNS për të rregulluar një problem që ndodh përpara se ajo fushë të lexohet ndonjëherë.

Pse bootstrap-i mund të ngecë

Always-on me bllokimin aktiv do të thotë që trafiku që nuk është brenda VPN-së hidhet, duke përfshirë trafikun e aplikacionit që zotëron VPN-në. Rruga e daljes është e qartë: aplikacioni thërret protect() në një socket, që e lidh atë me rrjetin bazë, kështu që ai anashkalon tunelin dhe lejohet të dalë. Çdo klient VPN duhet ta bëjë këtë për transportin e vet, përndryshe nuk do të arrinte kurrë një server.

Tani merrni parasysh një vendosje ku zgjidhësi i vetëm që e di emrin e pikës fundore është vetë brenda tunelit. Klienti ka nevojë për tunelin për të zgjidhur emrin, dhe për emrin për të ndërtuar tunelin. Kjo është një varësi e vërtetë rrethore, dhe asnjë konfigurim klienti nuk e zgjidh. Është gabim projektimi, jo një defekt.

Koha e zbulon të njëjtën varësi në forma më të buta. Në nisje, përpara shkyçjes së parë, pajisja mund të mos ketë ende një rrjet të përdorshëm; në një captive portal rrjeti ekziston, por bllokon gjithçka përveç portalit; në kalimin nga Wi-Fi në celular, rrjeti bazë i socket-it të mbrojtur ndryshon dhe klienti duhet ta vërejë dhe ta zgjidhë përsëri. Secila prej këtyre është një ngjarje bootstrap, dhe secila meriton të testohet qëllimisht në vend që të zbulohet në orën 3 të mëngjesit.

Pse fiksimi i përgjigjes nuk është zgjidhje

Rruga joshëse është të zgjidhësh emrin një herë dhe të ngjitësh adresën që rezulton në një fushë numerike, ose ta kodosh fort në një ndërtim të personalizuar. Duket se funksionon, dhe e kthen një emër në një fotografi. Kur operatori e zhvendos pikën fundore — një migrim, një ndryshim anycast, një adresë e re rajonale — klienti vazhdon të telefonojë atë të vjetër dhe asgjë në ndërfaqe nuk e shpjegon pse.

Regjistrimet DNS mbajnë një kohë jetëgjatësie pikërisht që përgjigjet të mund të ndryshojnë; ruajtja në memorie përcaktohet nga ajo kohë, jo përgjithmonë. Fiksimi i një përgjigjeje hedh poshtë mekanizmin që e bën një emër më të mirë se një adresë, ndërsa mban koston operative të përdorimit të një emri.

Fiksimi zakonisht shkon bashkë me një zakon të dytë të keq: zbutjen e kontrolleve të identitetit sepse lidhja tani dështon ndryshe. Verifikimi i identitetit të serverit nuk është pjesë e problemit të bootstrap-it, dhe dobësimi i tij shkëmben një shqetësim DNS me një rrezik përgjimi.

Dizenjime që i mbijetojnë një rinisjeje

Rregullimi i qëndrueshëm nuk është tërheqës. Përdor një klient që i implementon saktë socket-at e mbrojtur dhe e zgjidh pikën e vet fundore në rrjetin bazë, dhe jepi atij një emër pike fundore që zgjidhet publikisht, ose përmes një zgjidhësi të arritshëm përpara tunelit. Mbaje bllokimin aktiv; çaktivizimi i tij plotësisht që DNS të funksionojë heq vetinë për të cilën ekziston vendosja.

Aty ku pika fundore duhet të mbetet private, ofro një rrugë bootstrap të qartë që platforma mund të përdorë — një zgjidhës të arritshëm pa tunel, ose një lidhje administrimi që mbahet nga operatori — dhe mbaje atë përjashtim të ngushtë dhe në pronësi të politikës, jo të një çelësi përdoruesi. Dokumentacioni i Android VpnService është referenca për atë që platforma garanton për mbrojtjen dhe ciklin e jetës, dhe referenca e VpnService.Builder konfirmon se fusha DNS pranon adresa numerike.

Pastaj verifiko tre fazat, sipas radhës, në një lidhje të re pas një rinisjeje: emri i pikës fundore zgjidhet, tuneli vendoset dhe partneri autentikohet, dhe një emër privat zgjidhet përmes zgjidhësit të tunelit. Nëse faza e parë dështon, asgjë më pas nuk mund të funksionojë, dhe rregullimi i takon rrugës bootstrap — kurrë fushës së zgjidhësit.

• Zgjidhja e pikës fundore ndodh në aplikacion, jashtë tunelit, në një socket të mbrojtur.
• Fusha DNS e ndërtuesit është për aplikacionet brenda tunelit, jo për pikën fundore të vetë klientit.
• Një zgjidhës i arritshëm vetëm përmes tunelit është ngecje, jo nisje e ngadaltë.
• Testo veçmas pikën fundore, autentikimin dhe kërkimin privat pas një rinisjeje.