Android OpenVPN setzt keng Route derbäi ouni Tunneladress

Däin Android-OpenVPN-Profil füügt keng Route derbäi, well den Telefon keng Adress op der virtueller Interface huet, also gëtt et näischt, op dat eng Route weise kann. Route beäntwerten nëmmen, wou d Packete solle fortgoen. D Tunneladress beäntwert, wien den Telefon an dem Tunnel ass, an de Client muss eng liwweren, ier d Interface ka bestoen. Gitt déi véier Kontrollen hei ënnen an der Rei duerch a stoppt bei der éischter Feeler, well Route änneren ier d Adress existéiert dat richtegt Problem verstoppt.

Lies de Feeler an der Rei, an där de Client en ausféiert

VpnService.Builder vun Android hält déi zwou Konzepter getrennt: addAddress() setzt eng Adress op d Interface, déi d App baut, addRoute() füügt en Destination-Präfix derbäi, an establish() refuséiert d Interface ze schafen, bis op d mannst eng Adress derbäigesat gouf. En OpenVPN-Client mappt de Profil an d Optiounen, déi de Server schéckt, genee op déi Aufruffer, also kann eng Verbindung, déi ni eng Adress parst, d Interface guer net bauen.

Dofir kann d Loglinn, déi Dir liest, eng Route nennen, obwuel d Ursaach ee Schrëtt virdrun läit. De Client erreecht d Routestadium eréischt, wann d Interface existeiert; ouni Adress schléit den Route-Aufruff direkt feel oder leeft ni. Wann de Log seet, et kéint keng Route bäisetzen, fänkt mat der Adress un an net mat der Syntax vun der Route.

Kontroll 1: setzt de Server eng Adress an d Äntwert?

Bei engem gerouteten OpenVPN-Service kënnt d Adress aus dem Pool vum Server oder aus enger Zortéierung pro Client, an d Topologie decidéiert hir Form. Op engem Server mat OpenVPN 2.4 oder méi nei gesäit e Service mat Subnet-Topologie esou aus:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Mat där Form schéckt de Server eppes wéi ifconfig 10.8.0.6 255.255.255.0. Eng méi al Installatioun mat topology net30 schéckt amplaz eng Peeradress, zum Beispill ifconfig 10.8.0.6 10.8.0.5, also kann e Profil, deen tëscht den zwou Modeller geréckelt gouf, richteg ausgesäit, awer déi falsch Netmask dréit.

Sicht am Verbindungslog vum Client no deenen Optiounen, déi geschéckt goufen. Wann et do guer keng Linn ifconfig gëtt, huet de Server ni eng Adress geschéckt oder de Client huet d Optioun ofgeleent. Op engem Server, deen client-config-dir benotzt, muss d Fichier, déi nom common name vum Zertifikat benannt ass, existéieren an d Zortéierung droen:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontroll 2: behält de Client d Adress, déi en krut?

En ze breeden Filter ass déi zweet heefeg Ursaach. pull-filter gëtt et a OpenVPN 2.4 a méi nei, a wann e puer Filter op déi selwecht Optioun passen, gewënnt dee leschten, deen passt, also hëlt en catch-all um Enn d Adress ouni Feeler ewech:

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

Maacht de Filter esou schmuel wéi d Optioun, déi Dir wierklech wëllt ewech hunn, a loosst d Adress a Rou:

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

Den Avantage, all pull ofzeschalten, kënnt meeschtens vun engem, dee just eng eenzeg Route wëll lass ginn. route-nopull ass dee méi schmuele Schalter: en hält ifconfig an déi aner geschéckt Optiounen, wärend en déi geschéckt Route an DHCP-änlech Optiounen ofleet. Benotzt en, wann dat wierklech ass, wat Dir wëllt, a beäntwert d Fro vun der Adress getrennt.

Kontroll 3: ass d Adress deng ze tippen?

Manuell Adresséierung ass just legitim, wann den Operateur Iech de Wäert gëtt. Wann Dir selwer eng tippt, muss se aus dem Subnet vum VPN-Client kommen, ënner de aktive Sessiounen eenzegaarteg sinn an zu der Topologie passen, déi de Server lafe léisst. D Adress vun enger Desktop-Bréck oder engem Host um wäitem LAN ze kopéieren, schléit op béide Säiten feel: den Telefon géif eng Adress behaapten, déi et schonn anescht gëtt, an d Gateway hätt keen Zréckwee dohi.

De Präfix vum wäite LAN an enger Route ass en Destination, ni d Identitéit vum Telefon. Eng Route fir 10.60.0.0/24 seet, erreech dat Netzwierk duerch den Tunnel; si seet näischt doriwwer, wéi eng 10.60.0.x Adress den Telefon soll hunn, an den Telefon soll keng dovun hunn. Statesch Zortéierunge gehéieren op d Säit vum Server, wou se net mam dynamesche Pool kollidéiere kënnen.

Zwou Sessiounen op enger Identitéit leeën déiselwecht Kollisioun op. Wann dee selwechte Zertifikat zweemol verbënnt an de Server déi zwou déiselwecht fix Adress schéckt, duplizéiert déi zweet Sessioun déi éischt, an d Léisung sinn getrennt Identitéiten oder getrennt Zortéierungen amplaz vun enger Ännerung um Client.

Kontroll 4: hält eppes anescht de Tunnelslot?

Android erlaabt just ee aktive VPN-Service gläichzäiteg. Eng aner VPN-App oder en Always-on-VPN-Androch, deen ugeschalt blouf fir e Profil, deen net méi fonctionéiert, kann dee Slot huelen, ier däin OpenVPN-Client establish() oprufft. Dann erschéngt d Interface ni, obwuel de Profil gülteg ass, also trennt déi aner VPN, schalt d Always-on-Astellungs of a verbënnt Iech nei, ier Dir de Profil beréiert.

En Service, deen op Ethernet-Bridging insistéiert, ass déi aner Sakgaass. Eng Android-App ouni root kann en IP-Tunnel schafen, net en iwwerbréckte Ethernet-Segment, also mécht keng Adress, déi Dir tippt, e Server mat dev tap funktionéieren; den Operateur muss e geroutete Service ubidden. Wann Dir de Problem mësst, gitt den Numm an d Versioun vum Client, de geschéckten Optiounsset, d Topologie an dee geneeë Schrëtt un, wou d Adress hätt misse erschéngen.

Wann all véier Kontrollen duerchginn an d Adress do ass, eenzegaarteg a richteg maskéiert, gëtt d Fro vun der Route déi gewéinlech: wéi eng Präfixer de Server autoriséiert a wéi de Client se sollt ofgrenzen. Schreift d Tunneladress, hir Netmask an d Topologie op, ier Dir eppes anescht ännert, well déi dräi Wäerter sinn dat, wat den Operateur brauch, fir mat der Vue vum Server ze vergläichen.