Android OpenVPN sniðið þitt nær ekki að bæta við leið því síminn hefur ekkert fang á sýndarviðmótinu, svo ekkert er sem leið getur bent á. Leiðir svara aðeins því hvert pakkar eiga að fara. Göngufangið svarar því hver síminn er inni í göngunni, og biðlarinn verður að gefa eitt áður en viðmótið getur orðið til. Farðu í gegnum fjórar athuganir hér að neðan í röð og stöðvaðu við fyrstu mistök, því að breyta leiðum áður en fangið er til felur raunverulega vandamálið.

Lestu mistökin í þeirri röð sem biðlarinn framkvæmir þau

VpnService.Builder Android heldur hugtökunum tveimur aðgreindum: addAddress() setur fang á viðmótið sem appið er að byggja, addRoute() bætir við ákvörðunarforskeyti og establish() neitar að búa til viðmótið fyrr en að minnsta kosti einu fangi hefur verið bætt við. OpenVPN-biðlari varpar sniðinu og valkostunum sem þjónninn ýtir nákvæmlega á þessi köll, svo tenging sem þáttar aldrei fang getur alls ekki byggt viðmótið.

Þess vegna getur lóglínan sem þú lest nefnt leið þótt orsökin sé einu skrefi fyrr. Biðlarinn nær leiðarstiginu aðeins eftir að viðmótið er til; án fangs mistekst leiðarkallið strax eða keyrir aldrei. Þegar lógið segir að ekki sé hægt að bæta við leið skaltu byrja á fanginu en ekki á setningafræði leiðarinnar.

Athugun 1: setur þjónninn fang í svarið?

Fyrir beina OpenVPN-þjónustu kemur fangið úr laug þjónsins eða úthlutun fyrir hvern biðlara, og grannfræðin ræður lögun þess. Á OpenVPN 2.4 eða nýrri þjóni lítur þjónusta með undirneti-grannfræði svona út:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Með þeirri lögun ýtir þjónninn einhverju eins og ifconfig 10.8.0.6 255.255.255.0. Eldri uppsetning með topology net30 ýtir í staðinn jafningjafangi, til dæmis ifconfig 10.8.0.6 10.8.0.5, svo snið sem flutt er milli mókelsins tveggja getur litið rétt út á meðan það ber rangt netgrímu.

Leitaðu í tengilógi biðlarans að mengi valkostanna sem ýtt var. Ef það inniheldur enga ifconfig línu var þjónninn aldrei að senda fang eða biðlarinn hafnaði valkostinum. Á þjóni sem notar client-config-dir verður skráin nefnd eftir common name skírteinisins að vera til og bera úthlutunina:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Athugun 2: heldur biðlarinn fanginu sem honum var gefið?

Of breitt sía er önnur algenga orsökin. pull-filter er til í OpenVPN 2.4 og nýrri, og þegar margar síur passa við sama valkost vinnur sú síðasta sem passar, svo catch-all í lokin fjarlægir fangið án villu:

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

Þrengdu síuna að valkostinum sem þú vilt sannarlega losna við og láttu fangið ósnortið:

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

Ráðið að slökkva á öllum pull kemur venjulega frá einhverjum sem vill losna við eina leið. route-nopull er mjórri rofinn: hann heldur ifconfig og öðrum ýttum valkostum á meðan hann hafnar ýttum leiðum og DHCP-kenndum valkostum. Notaðu hann þegar það er sannarlega það sem þú vilt, og svaraðu fangsspurningunni sér.

Athugun 3: er fangið þitt til að slá inn?

Handvirk fangsetning er aðeins lögmæt þegar rekstraraðilinn afhendir þér gildið. Ef þú slærð inn eitt sjálf verður það að koma úr undirneti VPN-biðlarans, vera einkvæmt meðal virkra lota og passa við grannfræðina sem þjónninn keyrir. Að afrita fang brúar á skjáborði eða hýsils á fjarlæga LAN-inu mistekst á báða vegu: síminn myndi gera tilkall til fangs sem er þegar til annars staðar, og hliðið hefði enga leið til baka að því.

Forskeyti fjarlæga LAN-sins í leið er ákvörðunarstaður, aldrei auðkenni símans. Leið fyrir 10.60.0.0/24 segir að ná því neti í gegnum gönguna; hún segir ekkert um hvaða 10.60.0.x fang síminn ætti að hafa, og síminn ætti ekkert þeirra. Stöðug úthlutun tilheyrir þjónshliðinni, þar sem hún getur ekki rekist á kviku laugina.

Tvær lotur á einu auðkenni afhjúpa sömu árekstur. Ef sama skírteinið tengist tvisvar og þjónninn ýtir einu föstu fangi til beggja, afritar seinni lotan þá fyrstu, og lausnin er aðskilin auðkenni eða aðskilin úthlutun frekar en breyting á biðlarahlið.

Athugun 4: heldur eitthvað annað göngusætinu?

Android leyfir aðeins eina virka VPN-þjónustu í einu. Annað VPN-forrit, eða færsla fyrir alltaf-á VPN sem látin er virk fyrir snið sem virkar ekki lengur, getur tekið það sæti áður en OpenVPN-biðlarinn þinn kallar á establish(). Þá birtist viðmótið aldrei þótt sniðið sé gilt, svo aftengdu hina VPN-ina, slökktu á stillingunni alltaf-á og tengdu aftur áður en þú snertir sniðið.

Þjónusta sem krefst Ethernet-brúar er hinn blindgatan. Android-forrit án root getur búið til IP-göng, ekki brúaðan Ethernet-hluta, svo ekkert fang sem þú slærð inn fær dev tap þjón að virka; rekstraraðilinn verður að bjóða beina þjónustu. Þegar þú tilkynnir vandamálið skaltu láta fylgja nafn og útgáfu biðlarans, mengi ýttra valkosta, grannfræðina og það nákvæma skref þar sem fangið átti að birtast.

Ef allar fjórar athuganir standast og fangið er til staðar, einkvæmt og rétt grímað, verður leiðarspurningin hin venjulega: hvaða forskyptum þjónninn heimilar og hvernig biðlarinn á að afmarka þau. Skrifaðu niður göngufangið, netgrímu þess og grannfræðina áður en þú breytir nokkru öðru, því þessi þrjú gildi eru það sem rekstraraðilinn þarf að bera saman við sýn þjónsins.

Tengdir greinar