Android OpenVPN nepievieno maršrutu bez tuneļa adreses

Jūsu Android OpenVPN profils nepievieno maršrutu, jo tālrunim nav adreses virtuālajā saskarnē, tāpēc nav nekā, uz ko maršruts varētu norādīt. Maršruti atbild tikai uz to, kur pakešu jādodas. Tuneļa adrese atbild, kas ir tālrunis tuneļa iekšpusē, un klientam tā jānodrošina pirms saskarne var pastāvēt. Izejiet četras pārbaudes zemāk pēc kārtas un apstājieties pie pirmās kļūmes, jo maršrutu rediģēšana pirms adreses pastāvēšanas slēpj īsto problēmu.

Lasiet kļūdu tādā secībā, kādā to izpilda klients

Android VpnService.Builder tur abus jēdzienus atsevišķi: addAddress() ievieto adresi saskarnē, ko lietotne būvē, addRoute() pievieno galamērķa prefiksu, un establish() atsakās veidot saskarni, līdz ir pievienota vismaz viena adrese. OpenVPN klients profilu un servera nosūtītās opcijas attiecina tieši uz šiem izsaukumiem, tāpēc savienojums, kas nekad neanalizē adresi, saskarni vispār nevar uzbūvēt.

Tāpēc žurnāla rinda, ko lasāt, var nosaukt maršrutu, kamēr cēlonis ir vienu soli agrāk. Klients maršruta posmu sasniedz tikai pēc tam, kad saskarne pastāv; bez adreses maršruta izsaukums nekavējoties neizdodas vai vispār neizpildās. Kad žurnāls saka, ka nevar pievienot maršrutu, sāciet ar adresi, nevis ar maršruta sintaksi.

Pārbaude 1: vai serveris atbildē ievieto adresi?

Maršrutētā OpenVPN servisā adrese nāk no servera baseina vai no piešķīruma katram klientam, un tās formu nosaka topoloģija. OpenVPN 2.4 vai jaunākā serverī serviss ar apakštīkla topoloģiju izskatās šādi:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Ar šādu formu serveris nosūta kaut ko līdzīgu ifconfig 10.8.0.6 255.255.255.0. Vecāka topology net30 instalācija tā vietā nosūta partnera adresi, piemēram, ifconfig 10.8.0.6 10.8.0.5, tāpēc profils, kas pārvietots starp abiem modeļiem, var izskatīties pareizi, bet saturēt nepareizu tīkla masku.

Klienta savienojuma žurnālā meklējiet nosūtīto opciju kopu. Ja tajā vispār nav ifconfig rindas, serveris nekad nav sūtījis adresi vai klients ir noraidījis opciju. Serverī, kas izmanto client-config-dir, failam, kas nosaukts pēc sertifikāta common name, jāpastāv un jāsatur piešķīrums:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Pārbaude 2: vai klients saglabā saņemto adresi?

Pārāk plats filtrs ir otrs izplatītais cēlonis. pull-filter pastāv OpenVPN 2.4 un jaunākos, un, ja vairāki filtri atbilst vienai opcijai, uzvar pēdējais atbilstošais, tāpēc beigās atstāts catch-all noņem adresi bez kļūdas:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Sašauriniet filtru līdz opcijai, no kuras tiešām gribat atbrīvoties, un atstājiet adresi mierā:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Padoms izslēgt visus pull parasti nāk no kāda, kas grib atbrīvoties no viena vienīga maršruta. route-nopull ir šaurāks slēdzis: tas saglabā ifconfig un pārējās nosūtītās opcijas, bet noraida nosūtītos maršrutus un DHCP tipa opcijas. Izmantojiet to, kad tas tiešām ir tas, ko gribat, un adreses jautājumu risiniet atsevišķi.

Pārbaude 3: vai adrese ir jāraksta jums?

Manuāla adresēšana ir pamatota tikai tad, kad operators jums nodod vērtību. Ja ierakstāt to pats, tai jānāk no VPN klienta apakštīkla, jābūt unikālai starp aktīvajām sesijām un jāatbilst topoloģijai, ko izpilda serveris. Darbvirsmas tilta vai nuotālā LAN resursdatora adreses kopēšana neizdodas abos gadījumos: tālrunis pieprasītu adresi, kas jau pastāv citur, un vārtejai nebūtu atgriešanās ceļa uz to.

Nuotālā LAN prefikss maršrutā ir galamērķis, nekad tālruņa identitāte. Maršruts 10.60.0.0/24 saka: sasniedz šo tīklu pa tuneli; tas neko nesaka par to, kāda 10.60.0.x adrese tālrunim jābūt, un tālrunim nevajadzētu būt nevienai no tām. Statiski piešķīrumi pieder servera pusei, kur tie nevar sadurties ar dinamisko baseinu.

Divas sesijas ar vienu identitāti atklāj to pašu sadursmi. Ja viens sertifikāts pieslēdzas divreiz un serveris abiem nosūta vienu fiksētu adresi, otrā sesija dublē pirmo, un risinājums ir atsevišķas identitātes vai atsevišķi piešķīrumi, nevis klienta puses labojums.

Pārbaude 4: vai kaut kas cits aizņem tuneļa vietu?

Android atļauj tikai vienu aktīvu VPN servisu vienlaikus. Cita VPN lietotne vai vienmēr ieslēgta VPN ieraksts, kas atstāts ieslēgts profilam, kurš vairs nedarbojas, var aizņemt šo vietu pirms jūsu OpenVPN klients izsauc establish(). Tad saskarne nekad neparādās, lai gan profils ir derīgs, tāpēc atvienojiet otru VPN, izslēdziet vienmēr ieslēgtā iestatījumu un pievienojieties no jauna, pirms aiztiekat profilu.

Serviss, kas uzstāj uz Ethernet tiltu, ir otrs strupceļš. Android lietotne bez root var izveidot IP tuneli, nevis savienotu Ethernet segmentu, tāpēc neviena ievadīta adrese neliks dev tap serverim darboties; operatoram jāpiedāvā maršrutēts serviss. Kad ziņojat par problēmu, iekļaujiet klienta nosaukumu un versiju, nosūtīto opciju kopu, topoloģiju un precīzo soli, kurā adresei vajadzēja parādīties.

Ja visas četras pārbaudes iztur un adrese ir, unikāla un pareizi maskēta, maršruta jautājums kļūst parasto: kurus prefiksus serveris atļauj un kā klientam tie jāierobežo. Pierakstiet tuneļa adresi, tās tīkla masku un topoloģiju pirms kaut ko citu maināt, jo tieši šīs trīs vērtības operatoram jāsalīdzina ar servera skatījumu.