Android always-on VPN: paano unang nireresolba ang pangalan ng endpoint

Nag-reboot ang telepono, naka-on ang always-on, naka-on ang «harangin ang mga koneksyon na walang VPN», at hindi kailanman umangat ang tunnel. Walang mali sa configuration: ginagawa ng harang ang trabaho nito, at ang pagtatangkang maabot ng client mismo ang endpoint nito ay sakop din nito. Kailangang i-resolba ang pangalan ng endpoint bago pa umiral ang tunnel, ng isang client na pinapayagang makipag-usap sa network habang ang lahat ng iba pang app ay hindi. Ang pag-unawa kung aling bahagi ang gumagawa nito, at sa anong pagkakasunod-sunod, ang siyang nagpapalit ng misteryong ito tungo sa isang tanong sa configuration.

Ano ba talaga ang hinihiling ng VPN builder

Ang Android VPN app ay hindi nagbibigay sa platform ng address ng server. Gumagawa ito ng lokal na interface: mga address at ruta para sa tunnel, ang mga resolver na dapat gamitin ng mga app sa loob nito, at pagkatapos ay nagbabalik ang establish() ng file descriptor na binabasa at sinusulatan ng app bilang hilaw na IP packet. Ang remote na endpoint ay hindi lumilitaw sa builder na iyon.

Iyan ang pangunahing structural fact. Gumagawa ang platform ng tun interface at nagpapatupad ng patakaran dito; ipinapatupad ng app ang transport sa userspace, ibig sabihin, ang app mismo ang nagre-resolba ng pangalan ng endpoint nito at nagbubukas ng naka-encrypt na koneksyon. Kaya posible ang endpoint na anyo ng hostname — hindi dahil sinusuportahan ng platform ang mga pangalan, kundi dahil hindi kailanman nakikita ng platform ang endpoint.

May isang patlang sa builder na tumatanggap ng address: ang mga DNS server. Dapat silang numeric na address ng resolver, kadalasan ang mga nais tanungin ng operator sa pamamagitan ng tunnel. Inilalarawan ng patlang na iyon kung saan nagpapadala ng query ang mga app pagkatapos umangat ang tunnel. Wala itong sinasabi tungkol sa kung paano hinahanap ng client ang endpoint, at ang pagtrato sa dalawa bilang isang setting lang ang pinagmumulan ng kalituhan.

Dalawang tanong sa DNS, hindi isa

Ang unang tanong ay: saan nagpapadala ng query ang mga app kapag umangat na ang tunnel? Ang sagot ay isang address ng resolver sa loob ng tunnel, naaabot sa pamamagitan ng tun interface, at numeric ayon sa pagkakabuo.

Ang ikalawang tanong ay: paano hinahanap ng client ang sarili nitong endpoint bago pa umiral ang tunnel na iyon? Ang paghahanap na iyon ay nangyayari sa labas ng tunnel, sa underlying network, sa proseso ng client. Maaari itong gumamit ng pangalan, at dapat gumamit ng resolver na naaabot ng device nang walang VPN.

Tatlong yugto, tatlong magkaibang sintomas. Isang mensahe ng error na nagsasabing «hindi makakonekta» ang nagpagsasama-sama sa kanila, at iyon ang dahilan kung bakit nagsisimulang i-edit ng mga tao ang patlang ng DNS server para ayusin ang problemang nangyayari bago pa mabasa ang patlang na iyon.

Bakit maaaring matigil ang bootstrap

Ang always-on na may naka-on na harang ay nangangahulugang itinatapon ang trapikong wala sa loob ng VPN, kabilang ang trapiko ng app na nagmamay-ari ng VPN. Malinaw ang labasan: tinatawagan ng app ang protect() sa isang socket, na nagbibigkis nito sa underlying network kaya nilalabag nito ang tunnel at pinapayagang lumabas. Kailangang gawin ito ng bawat VPN client para sa sarili nitong transport, kung hindi ay hindi ito makakarating sa server.

Isaalang-alang ngayon ang isang deployment kung saan ang tanging resolver na nakakaalam ng pangalan ng endpoint ay nasa loob mismo ng tunnel. Kailangan ng client ang tunnel para i-resolba ang pangalan, at ang pangalan para itayo ang tunnel. Tunay iyon na circular dependency, at walang configuration ng client ang makakalutas nito. Iyon ay design error, hindi bug.

Inilalantad ng timing ang parehong dependency sa mas banayad na anyo. Sa boot bago ang unang pag-unlock, maaaring wala pang magagamit na network ang device; sa captive portal, may network ngunit hinaharangan ang lahat maliban sa portal; sa paglipat mula Wi-Fi patungo sa cellular, nagbabago ang underlying network ng protektadong socket at kailangang mapansin ito ng client at muling mag-resolba. Bawat isa sa mga iyon ay bootstrap event, at bawat isa ay dapat sadyang subukan kaysa matuklasan nang alas-3 ng madaling-araw.

Bakit hindi solusyon ang pagpirmi ng sagot

Ang mapang-akit na shortcut ay i-resolba ang pangalan nang isang beses at i-paste ang resultang address sa isang numeric na patlang, o i-hardcode ito sa custom na build. Mukhang gumagana ito, at ginagawa nitong larawan ang isang pangalan. Kapag inilipat ng operator ang endpoint — isang migrasyon, pagbabago ng anycast, bagong regional address — patuloy na tumatawag ang client sa luma at walang anumang nagpapaliwanag sa UI kung bakit.

May time to live ang mga DNS record para lang mabago ang mga sagot; ang caching ay tinutukoy ng tagal na iyon, hindi panghabambuhay. Ang pagpirmi ng sagot ay itinatapon ang mekanismong nagpapabuti sa pangalan kaysa sa address, habang pinapanatili ang operational na gastos ng paggamit ng pangalan.

Madalas sumama ang pagpirmi sa pangalawang masamang ugali: pagluwag sa mga pagsusuri ng pagkakakilanlan dahil naiiba nang nabibigo ang koneksyon. Ang beripikasyon ng pagkakakilanlan ng server ay hindi bahagi ng bootstrap problem, at ang pagpapahina nito ay nagpapalit ng abala sa DNS para sa panganib ng interception.

Mga design na nakakalampas sa reboot

Ang matibay na kaayusan ay hindi kagila-gilalas. Gumamit ng client na wastong nagpapatupad ng mga protektadong socket at nagre-resolba ng endpoint nito sa underlying network, at bigyan ito ng pangalan ng endpoint na nare-resolba nang publiko, o sa pamamagitan ng resolver na naaabot bago ang tunnel. Panatilihing naka-on ang harang; ang ganap na pagpatay nito para gumana ang DNS ay nag-aalis ng katangiang dahilan ng deployment.

Kung saan dapat manatiling pribado ang endpoint, magbigay ng malinaw na bootstrap path na magagamit ng platform — isang resolver na naaabot nang walang tunnel, o isang koneksyon sa pamamahala na pinapanatili ng operator — at panatilihing makitid ang eksepsiyong iyon at pag-aari ng patakaran, hindi ng toggle ng user. Ang dokumentasyon ng Android VpnService ang reference para sa kung ano ang ginagarantiya ng platform tungkol sa proteksyon at lifecycle, at ang reference ng VpnService.Builder ay kumukumpirma na tumatanggap ng numeric na address ang patlang ng DNS.

Pagkatapos, i-verify ang tatlong yugto, sa pagkakasunod-sunod, sa bagong koneksyon pagkatapos ng reboot: nare-resolba ang pangalan ng endpoint, naitatayo ang tunnel at nabe-verify ang peer, at nare-resolba ang pribadong pangalan sa pamamagitan ng resolver ng tunnel. Kung nabigo ang unang yugto, wala nang susunod na makakagana, at ang pagwawasto ay kabilang sa bootstrap path — hindi kailanman sa patlang ng resolver.

• Ang pag-resolba ng endpoint ay nangyayari sa app, sa labas ng tunnel, sa protektadong socket.
• Ang patlang ng DNS sa builder ay para sa mga app sa loob ng tunnel, hindi para sa sariling endpoint ng client.
• Ang resolver na naaabot lamang sa pamamagitan ng tunnel ay pagkatigil, hindi mabagal na simula.
• Subukan nang hiwalay ang endpoint, authentication, at pribadong paghahanap pagkatapos ng reboot.