Android always-on VPN: эцсийн цэгийн нэр хэрхэн хамгийн түрүүнд шийдэгддэг

Утас дахин ачаалж, always-on идэвхтэй, «VPN-гүй холболтыг блоклох» асаалттай байхад туннель огт босохгүй. Ямар ч буруу тохиргоо байхгүй: блоклолт өөрийн ажлыг хийж байгаа бөгөөд клиентийн өөрийн эцсийн цэгт хүрэх оролдлого ч мөн үүнд захирагдана. Эцсийн цэгийн нэрийг туннель үүсэхээс өмнө, бусад бүх апп-д зөвшөөрөлгүй байхад сүлжээтэй харилцах зөвшөөрөлтэй клиент шийдэх ёстой. Аль бүрэлдэхүүн үүнийг хийж, ямар дарааллаар хийдгийг ойлгох нь энэ нууцыг тохиргооны асуулт болгоно.

VPN бүтээгч үнэндээ юу шаарддаг

Android VPN апп платформд серверийн хаяг өгдөггүй. Энэ нь локал интерфэйс бүтээдэг: туннелийн хаяг ба маршрутууд, апп-ууд дотор нь ашиглах ёстой шийдэгчүүд, дараа нь establish() апп-ын түүхий IP пакет болгон уншиж, бичдэг файлын дескрипторийг буцаана. Алсын эцсийн цэг тэр бүтээгчид огт харагдахгүй.

Энэ бол гол бүтцийн баримт. Платформ tun интерфэйс үүсгэж, түүнд бодлого хэрэгжүүлдэг; апп хэрэглэгчийн орон зайд тээврийг хэрэгжүүлдэг, өөрөөр хэлбэл эцсийн цэгийн нэрийг шийдэж, шифрлэгдсэн холболтыг нээх ажлыг апп өөрөө хийдэг. Тиймээс хост нэр хэлбэрийн эцсийн цэг боломжтой — платформ нэр дэмждэг учраас биш, платформ эцсийн цэгийг хэзээ ч хардаггүй учраас.

Бүтээгчийн нэг талбар л хаяг авдаг: DNS серверүүд. Тэдгээр нь тоон шийдэгчийн хаяг байх ёстой, ихэвчлэн оператор туннелээр асуухыг хүсдэг хаягууд. Тэр талбар нь туннель боссны дараа апп-ууд асуулгыг хааша илгээдгийг тодорхойлно. Клиент эцсийн цэгийг хэрхэн олдог талаар юу ч хэлэхгүй бөгөөд эдгээр хоёрыг нэг тохиргоо гэж үзэхээс л төөрөгдөл эхэлдэг.

Нэг биш, хоёр DNS асуулт

Эхний асуулт: туннель боссны дараа апп-ууд асуулгыг хааша илгээдэг? Хариулт нь туннелийн доторх шийдэгчийн хаяг, tun интерфэйсээр хүрэх боломжтой, бүтцээрээ тоон.

Хоёр дахь асуулт: клиент өөрийн эцсийн цэгийг тэр туннель үүсэхээс өмнө хэрхэн олдог вэ? Тэр хайлт туннелийн гадна, доод сүлжээнд, клиентийн процесс дотор явагдана. Энэ нь нэр ашиглаж болно, мөн VPN-гүйгээр төхөөрөмж хүрэх боломжтой шийдэгч ашиглах ёстой.

Гурван үе шат, гурван өөр шинж тэмдэг. «Холбогдож чадахгүй» гэсэн нэг алдааны мэдээлэл тэдгээрийг нэгтгэдэг, тиймээс хүмүүс тэр талбарыг уншихаас өмнө болдог асуудлыг засах гэж DNS серверийн талбарыг засаж эхэлдэг.

Bootstrap яагаад гацаж болдог

Always-on блоклолт идэвхтэй байх нь VPN-ийн дотор ороогүй трафик хаягдана гэсэн үг, үүнд VPN-тэй апп-ын трафик ч орно. Гарах зам нь тодорхой: апп сокет дээр protect() дуудаж, энэ нь түүнийг доод сүлжээнд холбодог тул туннелийг тойрч, гадагш гарах зөвшөөрөл авдаг. VPN клиент бүр өөрийн тээврийн хувьд үүнийг хийх ёстой, эс тэгвээс серверт хэзээ ч хүрэхгүй.

Одоо эцсийн цэгийн нэрийг мэддэг цорын ганц шийдэгч нь өөрөө туннелийн дотор байдаг байршуулалтыг төсөөлье. Клиентэд нэрийг шийдэхийн тулд туннель, туннель барихын тулд нэр хэрэгтэй. Энэ бол жинхэнэ цикл хамаарал бөгөөд ямар ч клиентийн тохиргоо үүнийг шийдэхгүй. Энэ нь дизайны алдаа, программ хангамжийн алдаа биш.

Цаг хугацаа ижил хамаарлыг зөөлөн хэлбэрээр илрүүлдэг. Ачаалах үед, анхны түгжээ нээгдэхээс өмнө төхөөрөмжид ашиглах боломжтой сүлжээ байхгүй байж болно; captive portal дээр сүлжээ байгаа боловч порталаас бусад бүгдийг блоколдоно; Wi-Fi-аас үүрэн сүлжээнд шилжихэд хамгаалагдсан сокетын доод сүлжээ өөрчлөгдөж, клиент үүнийг анзаарч дахин шийдэх ёстой. Эдгээр бүр нь bootstrap үйл явдал бөгөөд шөнийн 3 цагт илрүүлэхээс илүү санаатайгаар туршиж үзэх нь зүйтэй.

Хариултыг бэхлэх нь яагаад шийдэл биш вэ

Уруу татдаг тойрч гарах зам нь нэрийг нэг удаа шийдэж гарсан хаягийг тоон талбарт нааж эсвэл захиалгат бүтээцэд хатуу кодлох юм. Ажиллаж байгаа мэт харагдана, нэрийг агшсан зураг болгоно. Оператор эцсийн цэгийг зөөхөд — шилжилт, anycast өөрчлөлт, шинэ бүс нутгийн хаяг — клиент хуучныг нь үргэлжлүүлэн дуудаж, интерфэйсэд яагаад гэдгийг юу ч тайлбарлахгүй.

DNS бичлэгүүдэд амьдрах хугацаа байгаа нь хариултууд өөрчлөгдөж болох учраас юм; кэшлэлт нь тэр хугацаагаар тодорхойлогдоно, үүрд биш. Хариултыг бэхлэх нь нэрийг хаягаас илүү болгодог механизмыг хаяж, нэр ашигласны ашиглалтын зардлыг хадгална.

Бэхлэлт нь ихэвчлэн хоёр дахь муу зуршилтай хамт явдаг: холболт одоо өөрөөр бүтэлгүйтдэг учраас таних шалгалтыг сулруулах. Серверийн таних шалгалт нь bootstrap асуудлын хэсэг биш бөгөөд үүнийг сулруулах нь DNS-ийн тав тухгүй байдлыг таслан сонсох эрсдэлээр солино.

Дахин ачааллыг давдаг дизайнууд

Тогтвортой зохицуулалт нь гоёл чимэггүй. Хамгаалагдсан сокетыг зөв хэрэгжүүлж, эцсийн цэгээ доод сүлжээнд шийддэг клиент ашиглаж, түүнд олон нийтэд эсвэл туннелийн өмнө хүрэх боломжтой шийдэгчээр шийдэгддэг эцсийн цэгийн нэр өг. Блоклолтыг асаалттай үлдээ; DNS ажиллахын тулд бүрэн унтраах нь байршуулалт оршин байх шалтгаан болсон шинж чанарыг устгана.

Эцсийн цэг нууц хэвээр байх ёстой газарт платформ ашиглаж болох тодорхой bootstrap зам гарга — туннельгүйгээр хүрэх боломжтой шийдэгч, эсвэл операторын хадгалдаг удирдлагын холболт — мөн тэр үл хамаарах зүйлийг нарийн байлгаж, хэрэглэгчийн унтраалгад биш, бодлогод хамааруул. Android VpnService-ийн баримт бичиг нь хамгаалалт ба амьдралын мөчлөгийн талаар платформ юу баталгаажуулдгийн лавлагаа бөгөөд VpnService.Builder-ийн лавлагаа DNS талбар тоон хаяг авдгийг батална.

Дараа нь дахин ачаалсны дараах шинэ холболт дээр гурван үе шатыг дарааллаар нь шалга: эцсийн цэгийн нэр шийдэгдэнэ, туннель тогтоож, хос таних баталгаажина, хувийн нэр туннелийн шийдэгчээр шийдэгдэнэ. Эхний шат бүтэлгүйтвэл дараагийн юу ч ажиллахгүй бөгөөд засвар нь bootstrap замд хамаарна — хэзээ ч шийдэгчийн талбарт биш.

• Эцсийн цэгийн шийдэлт апп дотор, туннелийн гадна, хамгаалагдсан сокет дээр явагдана.
• Бүтээгч дэх DNS талбар нь туннелийн доторх апп-уудад зориулагдсан, клиентийн өөрийн эцсийн цэгт биш.
• Зөвхөн туннелээр хүрэх боломжтой шийдэгч бол гацалт, удаан эхлэл биш.
• Дахин ачаалсны дараа эцсийн цэг, таних баталгаажуулалт, хувийн хайлтыг тус тусад нь турш.