Android always-on VPN: kā pirmais tiek atrisināts galapunkta nosaukums

Tālrunis pārstartējas, always-on ir ieslēgts, «bloķēt savienojumus bez VPN» ir ieslēgts, bet tunelis tā arī nepaceļas. Nekas nav nepareizi nokonfigurēts: bloķēšana dara savu darbu, un arī paša klienta mēģinājums sasniegt savu galapunktu tai pakļaujas. Galapunkta nosaukums ir jāatrisina pirms tuneļa pastāvēšanas, un to dara klients, kuram atļauts sazināties ar tīklu, kamēr visām pārējām lietotnēm tas nav atļauts. Izpratne par to, kura komponente to dara un kādā secībā, pārvērš šo mīklu konfigurācijas jautājumā.

Ko VPN veidotājs patiešām pieprasa

Android VPN lietotne nenodod platformai servera adresi. Tā veido lokālu saskarni: tuneļa adreses un maršrutus, atrisinātājus, kas lietotnēm jāizmanto tā iekšienē, un tad establish() atgriež faila deskriptoru, ko lietotne lasa un raksta kā neapstrādātus IP paketes. Attālais galapunkts šajā veidotājā nemaz neparādās.

Tas ir galvenais strukturālais fakts. Platforma izveido tun saskarni un tai piemēro politiku; lietotne īsteno transportu lietotāja telpā, tas nozīmē, ka pati lietotne atrisina sava galapunkta nosaukumu un atver šifrēto savienojumu. Tāpēc galapunkts resursdatora nosaukuma veidā ir iespējams — ne tāpēc, ka platforma atbalsta nosaukumus, bet tāpēc, ka platforma galapunktu nekad neredz.

Viens veidotāja lauks tomēr pieņem adreses: DNS serveri. Tiem jābūt ciparu atrisinātāju adresēm, parasti tām, ko operators vēlas vaicāt caur tuneli. Šis lauks apraksta, kur lietotnes sūta vaicājumus pēc tam, kad tunelis ir pacēlies. Tas neko nesaka par to, kā klients atrod galapunktu, un tieši šo divu uzstādījumu pielīdzināšana ir apjukuma sākums.

Divi DNS jautājumi, nevis viens

Pirmais jautājums: kur lietotnes sūta vaicājumus, kad tunelis jau pacēlies? Atbilde ir atrisinātāja adrese tuneļa iekšienē, sasniedzama caur tun saskarni un pēc uzbūves ciparu formā.

Otrais jautājums: kā klients atrod savu galapunktu pirms šī tuneļa pastāvēšanas? Šī meklēšana notiek ārpus tuneļa, apakšējā tīklā, klienta procesā. Tā var izmantot nosaukumu, un tai jāizmanto atrisinātājs, ko ierīce sasniedz bez VPN.

Trīs posmi, trīs atšķirīgi simptomi. Viens kļūdas ziņojums «nevar savienoties» tos sapludina, un tāpēc cilvēki sāk labot DNS servera lauku, lai novērstu problēmu, kas rodas vēl pirms šis lauks tiek izlasīts.

Kāpēc bootstrap var nonākt strupceļā

Always-on ar ieslēgtu bloķēšanu nozīmē, ka satiksme, kas nav VPN iekšienē, tiek izmesta, tostarp lietotnes, kurai pieder VPN, satiksme. Izeja ir skaidra: lietotne izsauc protect() uz ligzdas, kas to piesaista apakšējam tīklam, tāpēc tā apiet tuneli un tai atļauj iziet. Katram VPN klientam tas jādara sava transporta dēļ, citādi tas nekad nesasniegs serveri.

Tagad aplūkosim izvietojumu, kur vienīgais atrisinātājs, kas zina galapunkta nosaukumu, pats atrodas tuneļa iekšienē. Klientam vajag tuneli, lai atrisinātu nosaukumu, un nosaukumu, lai uzbūvētu tuneli. Tā ir īsta cirkulāra atkarība, un neviena klienta konfigurācija to neatrisina. Tā ir projektēšanas kļūda, nevis kļūda programmā.

Laiks atklāj šo pašu atkarību maigākās formās. Palaišanas laikā pirms pirmās atslēgas atvēršanas ierīcei var vēl nebūt derīga tīkla; captive portal gadījumā tīkls ir, bet bloķē visu, izņemot portālu; pārejot no Wi-Fi uz mobilo tīklu, aizsargātās ligzdas apakšējais tīkls mainās, un klientam tas jāpamana un no jauna jāatrisina. Katrs no tiem ir bootstrap notikums, un katru ir vērts apzināti pārbaudīt, nevis atklāt 3 naktī.

Kāpēc atbildes fiksēšana nav risinājums

Kārdinošais apvedceļš ir vienreiz atrisināt nosaukumu un ielīmēt iegūto adresi ciparu laukā vai iekodēt to pielāgotā būvējumā. Tas šķietami strādā, un tas pārvērš nosaukumu momentuzņēmumā. Kad operators pārvieto galapunktu — migrācija, anycast izmaiņa, jauna reģionālā adrese — klients turpina zvanīt vecajam, un nekas saskarnē nepaskaidro kāpēc.

DNS ierakstiem ir dzīves ilgums tieši tāpēc, ka atbildes drīkst mainīties; kešošana tiek definēta pēc šī ilguma, nevis uz mūžu. Atbildes fiksēšana atmet mehānismu, kas nosaukumu padara labāku par adresi, vienlaikus saglabājot ekspluatācijas izmaksas par to, ka nosaukums tika izmantots.

Fiksēšana mēdz nākt kopā ar otru sliktu ieradumu: vājināt identitātes pārbaudi, jo savienojums tagad neizdodas citādi. Servera identitātes verifikācija nav bootstrap problēmas daļa, un tās vājināšana apmaina DNS neērtību pret pārtveršanas risku.

Risinājumi, kas pārdzīvo pārstartēšanu

Ilgtspējīgais risinājums nav grezns. Izmanto klientu, kas pareizi īsteno aizsargātās ligzdas un atrisina savu galapunktu apakšējā tīklā, un piešķir tam galapunkta nosaukumu, kas atrisinās publiski vai caur atrisinātāju, kurš sasniedzams pirms tuneļa. Atstāj bloķēšanu ieslēgtu; pilnīga tās izslēgšana, lai DNS strādātu, noņem to īpašību, kuras dēļ izvietojums pastāv.

Kur galapunktam jāpaliek privātam, nodrošini skaidru bootstrap ceļu, ko platforma var izmantot — atrisinātāju, kas sasniedzams bez tuneļa, vai operatora uzturētu pārvaldības savienojumu — un turi šo izņēmumu šauru un politikas pārvaldītu, nevis lietotāja slēdža. Android VpnService dokumentācija ir atsauce uz to, ko platforma garantē aizsardzībā un dzīves ciklā, un VpnService.Builder atsauce apstiprina, ka DNS lauks pieņem ciparu adreses.

Pēc tam pārbaudi trīs posmus pēc kārtas jaunā savienojumā pēc pārstartēšanas: galapunkta nosaukums atrisinās, tunelis izveidojas un partneris autentificējas, un privāts nosaukums atrisinās caur tuneļa atrisinātāju. Ja pirmais posms neizdodas, nekas turpmākais nevar strādāt, un labojums pieder bootstrap ceļam — nekad atrisinātāja laukam.

• Galapunkta atrisināšana notiek lietotnē, ārpus tuneļa, uz aizsargātas ligzdas.
• Veidotāja DNS lauks ir lietotnēm tuneļa iekšienē, nevis paša klienta galapunktam.
• Atrisinātājs, kas sasniedzams tikai caur tuneli, ir strupceļš, nevis lēna palaišana.
• Pēc pārstartēšanas atsevišķi pārbaudi galapunktu, autentifikāciju un privāto nosaukumu atrisināšanu.