Android always-on VPN: hvernig endapunktanafnið leysist fyrst

Síminn endurræsist, always-on er virkt, «loka tengingum án VPN» er á, og göngin koma aldrei upp. Ekkert er rangt stillt: lokunin sinnir sínu verki, og tilraun biðlarans til að ná sínum eigin endapunkti er háð henni. Endapunktanafnið verður að leysa áður en göngin eru til, af biðlara sem má tala við netið á meðan öll önnur forrit mega það ekki. Að skilja hvaða eining gerir það, og í hvaða röð, er það sem breytir þessari gátu í stillingarspurningu.

Hvað VPN-byggjarinn biður í raun um

Android VPN-forrit afhendir pallinum ekki netfangsþjón. Það byggir staðbundið viðmót: netföng og leiðir fyrir göngin, uppflettana sem forrit eiga að nota inni í þeim, og þá skilar establish() skráarlykli sem forritið les og skrifar sem hrá IP-pakka. Fjarlægi endapunkturinn kemur alls ekki fram í þeim byggja.

Þetta er lykilatriði uppbyggingarinnar. Pallurinn býr til tun-viðmót og framfylgir stefnu á því; forritið útfærir flutninginn í notendarými, sem þýðir að forritið sjálft leysir endapunktanafnið og opnar dulkóðuðu tenginguna. Endapunktur í formi hýsinakts er því mögulegur — ekki vegna þess að pallurinn styðji nöfn, heldur vegna þess að pallurinn sér endapunktinn aldrei.

Eitt svið í byggjanum tekur þó við netföngum: DNS-netþjónarnir. Þeir verða að vera töluleg uppflettanetföng, yfirleitt þau sem rekstraraðilinn vill láta spyrja í gegnum göngin. Þetta svið lýsir því hvert forrit senda fyrirspurnir eftir að göngin eru komin upp. Það segir ekkert um hvernig biðlarinn finnur endapunktinn, og að meðhöndla þessar tvær stillingar sem eina er þaðan sem ruglingurinn byrjar.

Tvær DNS-spurningar, ekki ein

Fyrsta spurningin: hvert senda forrit fyrirspurnir þegar göngin eru komin upp? Svarið er uppflettanetfang inni í göngunum, aðgengilegt í gegnum tun-viðmótið, og tölulegt að uppbyggingu.

Önnur spurningin: hvernig finnur biðlarinn sinn eigin endapunkt áður en þessi göng eru til? Sú uppfletting fer fram utan ganganna, á undirliggjandi netinu, í ferli biðlarans. Hún má nota nafn, og hún verður að nota uppflettu sem tækið nær án VPN.

Þrjú stig, þrjú mismunandi einkenni. Ein villuskilaboð sem segja «get ekki tengst» steypa þeim saman, og þess vegna enda menn á að breyta DNS-netþjónasviðinu til að laga vandamál sem á sér stað áður en sviðið er nokkurn tíma lesið.

Hvers vegna bootstrap getur stíflast

Always-on með virkri lokun þýðir að umferð sem er ekki inni í VPN er hent, þar á meðal umferð frá forritinu sem á VPN-ið. Útgangan er skýr: forritið kallar protect() á socket, sem bindur það við undirliggjandi net svo það fari fram hjá göngunum og fái að fara út. Sérhver VPN-biðlari verður að gera þetta fyrir eigin flutning, annars nær hann aldrei þjóni.

Hugleiddu nú uppsetningu þar sem eina uppflettan sem þekkir endapunktanafnið er sjálf inni í göngunum. Biðlarinn þarf göngin til að leysa nafnið og nafnið til að byggja göngin. Þetta er raunveruleg hringlaga ósjálfstæði, og engin biðlarastilling leysir hana. Þetta er hönnunarvilla, ekki galli.

Tímasetning sýnir sömu ósjálfstæði í mildari formum. Við ræsingu fyrir fyrstu opnun getur tækið ekki haft nothæft net enn; á captive portal er netið til en lokar á allt nema gáttina; við skipti úr Wi-Fi yfir í farsímanet breytist undirliggjandi net hins varða socket og biðlarinn verður að taka eftir því og leysa aftur. Hvert þessara er bootstrap-atburður, og hvert er þess virði að prófa viljandi frekar en að uppgötva klukkan 3 á nóttunni.

Hvers vegna að festa svarið er ekki lausn

Hin freistandi hjáleið er að leysa nafnið einu sinni og líma netfangið sem kemur út í tölulegt svið, eða harðkóða það í sérsmíðaða byggingu. Það virðist virka, og það breytir nafni í skyggnu. Þegar rekstraraðilinn flytur endapunktinn — flutningur, anycast-breyting, nýtt svæðisnetfang — heldur biðlarinn áfram að hringja í þann gamla og ekkert í viðmótinu útskýrir hvers vegna.

DNS-færslur bera líftíma einmitt svo að svör geti breyst; skyndiminni er skilgreint út frá þeim líftíma en ekki að eilífu. Að festa svar hendir þeirri aðferð sem gerir nafn betra en netfang, á meðan rekstrarkostnaðurinn af því að hafa notað nafn helst.

Festing fylgir líka oft annarri slæmri venju: að slaka á auðkenningarskoðun vegna þess að tengingin bregst nú á annan hátt. Sannprófun auðkennis þjónsins er ekki hluti af bootstrap-vandanum, og að veikja hana skiptir á óþægindum DNS fyrir hættu á hlerun.

Hönnun sem lifir endurræsingu

Varanlega fyrirkomulagið er ekki glæsilegt. Notaðu biðlara sem útfærir varða socket rétt og leysir endapunkt sinn á undirliggjandi netinu, og gefðu honum endapunktanafn sem leysist opinberlega, eða í gegnum uppflettu sem er aðgengileg fyrir göngin. Hafðu lokunina virka; að slökkva algjörlega á henni svo DNS virki fjarlægir þá eiginleika sem uppsetningin er til fyrir.

Þar sem endapunkturinn verður að vera einkalegur skaltu bjóða upp á skýra bootstrap-leið sem pallurinn getur notað — uppflettu sem er aðgengileg án ganganna, eða stjórntengingu sem rekstraraðilinn viðheldur — og haltu þeirri undantekningu þröngri og í eigu stefnu en ekki notendastökks. Android VpnService-skjölin eru viðmiðið fyrir það sem pallurinn ábyrgist um vernd og lífsferil, og VpnService.Builder-viðmiðið staðfestir að DNS-sviðið tekur við tölulegum netföngum.

Staðfestu síðan stigin þrjú, í röð, á nýrri tengingu eftir endurræsingu: endapunktanafnið leysist, göngin koma upp og jafninginn auðkennist, og einkanafn leysist í gegnum uppflettu ganganna. Ef fyrsta stigið bregst getur ekkert síðara virkað, og viðgerðin á heima í bootstrap-leiðinni — aldrei í uppflettusviðinu.

• Uppfletting endapunkts fer fram í forritinu, utan ganganna, á varða socket.
• DNS-sviðið í byggjanum er fyrir forrit inni í göngunum, ekki fyrir eigin endapunkt biðlarans.
• Uppfletta sem er aðeins aðgengileg í gegnum göngin er stífla, ekki hæg ræsing.
• Prófaðu endapunkt, auðkenningu og einkauppflettingu aðskilið eftir endurræsingu.