Android OpenVPN foeget gjin rûte ta sûnder tunneladres

Dyn Android-OpenVPN-profyl foeget gjin rûte ta, om t de telefoan gjin adres op de firtuele ynterface hat, dus is der neat dêr t in rûte nei wize kin. Rûtes beantwurdzje allinne wêr t pakketten hinne moatte. It tunneladres beantwurdet wa t de telefoan yn de tunnel is, en de klant moat ien leverje foar t de ynterface bestean kin. Rin de fjouwer kontrôles hjirûnder yn folchoarder troch en stop by de earste flater, want rûtes bewurkje foar t it adres bestiet ferberget it echte probleem.

Lês de flater yn de folchoarder wêryn de klant him útfiere

De VpnService.Builder fan Android hâldt de beide begripen skieden: addAddress() set in adres op de ynterface dy t de app bout, addRoute() foeget in bestimmingsprefiks ta, en establish() wegert de ynterface te meitsjen oant teminsten ien adres tafoege is. In OpenVPN-klant mappet it profyl en de opsjes dy t de tsjinner stjoert krekt op dy oanroppen, dus in ferbining dy t nea in adres parset kin de ynterface hielendal net bouwe.

Dêrom kin de logrigel dy t jo lêze in rûte neame wylst de oarsaak ien stap earder sit. De klant berikt de rûtefaze pas nei t de ynterface bestiet; sûnder adres mislearret de rûte-oprop daliks of rint nea. As de log seit dat er gjin rûte tafoegje kin, begjin dan by it adres en net by de syntaksis fan de rûte.

Kontrôle 1: set de tsjinner in adres yn it antwurd?

Foar in rûtearre OpenVPN-tsjinst komt it adres út de poel fan de tsjinner of út in tawizing per klant, en de topology beslút hokker foarm it hat. Op in OpenVPN 2.4 of nijere tsjinner sjocht in tsjinst mei subnet-topology der sa út:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Mei dy foarm stjoert de tsjinner eat as ifconfig 10.8.0.6 255.255.255.0. In âldere topology net30-ynstallaasje stjoert ynstee in peeradres, bygelyks ifconfig 10.8.0.6 10.8.0.5, dus in profyl dat tusken de twa modellen ferhuze is kin der goed útsjen wylst it it ferkearde netmasker draacht.

Sykje yn de ferbiningslog fan de klant nei de set opsjes dy t stjoerd binne. Sit dêr hielendal gjin rigel ifconfig yn, dan hat de tsjinner nea in adres stjoerd of de klant hat de opsje wegere. Op in tsjinner dy t client-config-dir brûkt, moat it bestân neamd nei de common name fan it sertifikaat bestean en de tawizing drage:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontrôle 2: hâldt de klant it adres dat er krigen hat?

In filter dat te breed is, is de twadde gewoane oarsaak. pull-filter bestiet yn OpenVPN 2.4 en nijer, en as meardere filters op deselde opsje passe, wint de lêste dy t past, dus in catch-all efteroan ferwideret it adres sûnder flater:

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

Behein it filter ta de opsje dy t jo echt kwyt wolle en lit it adres gewurde:

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

It advys om alle pulls út te setten komt meast fan immen dy t fan ien inkelde rûte ôf wol. route-nopull is de smelere skeakel: hy hâldt ifconfig en de oare stjoerde opsjes wylst er stjoerde rûtes en DHCP-achtige opsjes wegeret. Brûk him as dat echt is wat jo wolle, en beäntwurdzje de fraach oer it adres apart.

Kontrôle 3: is it adres fan jo om te typen?

Hânmjittich adressearjen is allinnich rjochtfeardige as de operator jo de wearde jout. Typje jo sels ien, dan moat er út it subnet fan de VPN-klant komme, unyk wêze ûnder aktive sesjes en oerienkomme mei de topology dy t de tsjinner rint. It adres fan in buroblêdbrêge of in host op de fiere LAN kopiearje mislearret op beide punten: de telefoan soe in adres opeaskje dat al earne oars bestiet, en de gateway soe gjin weromwei dêrhinne hawwe.

It fiere LAN-prefiks yn in rûte is in bestimming, nea de identiteit fan de telefoan. In rûte foar 10.60.0.0/24 seit: berik dat netwurk troch de tunnel; it seit neat oer hokker 10.60.0.x-adres de telefoan hâlde moat, en de telefoan moat gjinien fan harren hâlde. Statyske tawizings hearre by de tsjinnerkant, dêr t se net botsje kinne mei de dynamyske poel.

Twa sesjes op ien identiteit lizze deselde botsing bleat. As itselde sertifikaat twa kear ferbynt en de tsjinner ien fêst adres nei beide stjoert, duplisearret de twadde sesje de earste, en aparte identiteiten of aparte tawizings binne de oplossing ynstee fan in bewurking oan de klantkant.

Kontrôle 4: hâldt eat oars it tunnelslot?

Android lit mar ien aktive VPN-tsjinst tagelyk ta. In oare VPN-app, of in altyd-oan-VPN-ynstap dy t oan litten is foar in profyl dat net mear wurket, kin dat slot nimme foar t jo OpenVPN-klant establish() oanropt. Dan ferskynt de ynterface nea, ek al is it profyl jildich, dus ûntkoppelje de oare VPN, set de altyd-oan-ynstelling út en ferbyn op nij foar t jo it profyl oanreitsje.

In tsjinst dy t op Ethernet-bridging stiet, is de oare deade ein. In Android-app sûnder root kin in IP-tunnel meitsje, gjin brêge Ethernet-segment, dus gjin adres dat jo typje sil in dev tap-tsjinner wurkje litte; de operator moat in rûtearre tsjinst biede. As jo it probleem melde, jou dan de namme en ferzje fan de klant, de stjoerde set opsjes, de topology en de krekte stap wêr t it adres ferskine moatten hie.

As alle fjouwer kontrôles slagje en it adres is oanwêzich, unyk en goed maskearre, dan wurdt de rûtefraach de gewoane: hokker prefiksen de tsjinner machtiget en hoe t de klant se ôfbeakene moat. Skriuw it tunneladres, syn netmasker en de topology op foar t jo eat oars feroarje, want dy trije wearden binne wat de operator nedich hat om mei de tsjinnerside te ferlykjen.