Hindi nagdadagdag ng ruta ang OpenVPN sa Android kung walang address ng tunnel

Ang profile mong OpenVPN sa Android ay hindi nakakapagdagdag ng ruta dahil walang address ang telepono sa virtual na interface, kaya walang mapagpapatungan ng ruta. Sinasagot lamang ng mga ruta kung saan dapat pumunta ang mga packet. Sinasagot ng address ng tunnel kung sino ang telepono sa loob ng tunnel, at kailangang magbigay ng isa ang kliyente bago umiral ang interface. Dumaan sa apat na pagsusuri sa ibaba nang sunod-sunod at huminto sa unang kabiguan, dahil ang pag-edit ng ruta bago umiral ang address ay nagtatago ng tunay na problema.

Basahin ang kabiguan sa pagkakasunod-sunod na isinasagawa ito ng kliyente

Ang VpnService.Builder ng Android ay pinaghihiwalay ang dalawang konsepto: naglalagay ang addAddress() ng address sa interface na itinatayo ng app, nagdadagdag ang addRoute() ng prefix ng destinasyon, at tumatanggi ang establish() na gumawa ng interface hanggang may maidagdag na kahit isang address. Iniaayon ng kliyente ng OpenVPN ang profile at ang mga opsyong ipinapadala ng server nang eksakto sa mga tawag na iyon, kaya ang koneksyong hindi kailanman nag-aanalisa ng address ay hindi makakabuo ng interface.

Kaya maaaring banggitin ng log line na binabasa mo ang isang ruta habang ang sanhi ay isang hakbang na nauna. Nakarating lamang ang kliyente sa yugto ng ruta pagkatapos umiral ang interface; kung walang address, agad na nabigo ang tawag sa ruta o hindi ito tumatakbo. Kapag sinabi ng log na hindi ito makapagdagdag ng ruta, magsimula sa address at hindi sa syntax ng ruta.

Pagsusuri 1: naglalagay ba ang server ng address sa sagot?

Para sa rutadong serbisyo ng OpenVPN, ang address ay nagmumula sa pool ng server o sa paglalaan sa bawat kliyente, at ang topolohiya ang nagtatakda ng hugis nito. Sa server na OpenVPN 2.4 o mas bago, ganito ang hitsura ng serbisyong may topolohiyang subnet:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Sa ganoong hugis, nagpapadala ang server ng tulad ng ifconfig 10.8.0.6 255.255.255.0. Ang mas lumang pag-install na topology net30 ay nagpapadala ng address ng peer sa halip, halimbawa ifconfig 10.8.0.6 10.8.0.5, kaya ang profile na inilipat sa pagitan ng dalawang modelo ay maaaring magmukhang tama habang may dalang maling netmask.

Hanapin sa log ng koneksyon ng kliyente ang hanay ng mga opsyong ipinadala. Kung wala itong kahit isang linya ng ifconfig, hindi kailanman nagpadala ng address ang server o tinanggihan ng kliyente ang opsyong iyon. Sa server na gumagamit ng client-config-dir, dapat umiral ang file na pinangalanan ayon sa common name ng sertipiko at dapat naglalaman ito ng paglalaan:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Pagsusuri 2: pinapanatili ba ng kliyente ang address na natanggap?

Ang masyadong malawak na filter ang pangalawang karaniwang dahilan. Umiiral ang pull-filter sa OpenVPN 2.4 at mas bago, at kapag maraming filter ang tumutugma sa parehong opsyon, ang huling tumutugma ang nananalo, kaya ang catch-all sa dulo ay nag-aalis ng address nang walang error:

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

Paliitin ang filter sa opsyong talagang gusto mong alisin at hayaang manatili ang address:

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

Ang payong huwag paganahin ang lahat ng pull ay karaniwang galing sa taong gustong alisin ang isang ruta lamang. Ang route-nopull ang mas makitid na switch: pinapanatili nito ang ifconfig at ang iba pang ipinadalang opsyon habang tinatanggihan ang ipinadalang ruta at mga opsyong tulad ng DHCP. Gamitin ito kapag talagang iyon ang gusto mo, at sagutin nang hiwalay ang tanong tungkol sa address.

Pagsusuri 3: address mo ba ito para i-type?

Ang manu-manong paglalagay ng address ay lehitimo lamang kapag ibinigay sa iyo ng operator ang halaga. Kung ikaw mismo ang magta-type, kailangang manggaling ito sa subnet ng kliyente ng VPN, maging natatangi sa mga aktibong sesyon at tumugma sa topolohiyang pinapatakbo ng server. Ang pagkopya ng address ng desktop bridge o ng host sa malayong LAN ay nabibigo sa dalawang dahilan: sasabihin ng telepono na may address itong talagang umiiral na sa ibang lugar, at wala sanang daan pabalik ang gateway papunta rito.

Ang prefix ng malayong LAN sa isang ruta ay destinasyon, hindi kailanman pagkakakilanlan ng telepono. Ang rutang para sa 10.60.0.0/24 ay nagsasabing maabot ang network na iyon sa pamamagitan ng tunnel; wala itong sinasabi tungkol sa kung aling address na 10.60.0.x ang dapat hawakan ng telepono, at wala dapat hawakan ang telepono sa mga iyon. Ang mga static na paglalaan ay kabilang sa panig ng server, kung saan hindi sila maaaring bumangga sa dinamikong pool.

Dalawang sesyon sa isang pagkakakilanlan ang naglalantad ng parehong banggaan. Kung ang parehong sertipiko ay kumokonekta nang dalawang beses at isang fixed na address ang ipinapadala ng server sa dalawa, dinodoble ng ikalawang sesyon ang una, at ang solusyon ay hiwalay na pagkakakilanlan o hiwalay na paglalaan, hindi pag-edit sa panig ng kliyente.

Pagsusuri 4: may ibang bagay bang sumasakop sa puwesto ng tunnel?

Isang aktibong serbisyo ng VPN lamang ang pinapayagan ng Android sa isang pagkakataon. Ang ibang app ng VPN, o entry ng always-on VPN na naiwang bukas para sa profile na hindi na gumagana, ay maaaring kumuha ng puwestong iyon bago tawagan ng iyong kliyente ng OpenVPN ang establish(). Hindi na lilitaw ang interface kahit wasto ang profile, kaya idiskonekta ang ibang VPN, patayin ang setting ng always-on at kumonekta muli bago hawakan ang profile.

Ang serbisyong nagpipilit ng Ethernet bridging ang isa pang dead end. Ang app ng Android na walang root ay makakagawa ng IP tunnel, hindi bridged na segment ng Ethernet, kaya walang address na ita-type mo ang magpapatakbo sa server na dev tap; kailangang mag-alok ng rutadong serbisyo ang operator. Kapag iniuulat mo ang problema, isama ang pangalan at bersyon ng kliyente, ang hanay ng ipinadalang opsyon, ang topolohiya at ang eksaktong hakbang kung saan dapat lumitaw ang address.

Kung pumasa ang apat na pagsusuri at ang address ay naroroon, natatangi at wastong naka-mask, ang tanong tungkol sa ruta ay magiging karaniwan: aling mga prefix ang pinapayagan ng server at paano dapat limitahan ito ng kliyente. Isulat ang address ng tunnel, ang netmask at ang topolohiya bago magbago ng anupaman, dahil ang tatlong halagang iyon ang kailangang ihambing ng operator sa pananaw ng server.