OpenVPN në Android nuk shton rrugë pa adresë tuneli

Profili juaj OpenVPN në Android nuk shton rrugë sepse telefoni nuk ka adresë në ndërfaqen virtuale, pra nuk ka asgjë ku një rrugë të mund të tregojë. Rrugët përgjigjen vetëm se ku duhet të shkojnë paketat. Adresa e tunelit përgjigjet se kush është telefoni brenda tunelit, dhe klienti duhet të japë një para se ndërfaqja të mund të ekzistojë. Kaloni nëpër katër kontrollet më poshtë me radhë dhe ndaloni në dështimin e parë, sepse redaktimi i rrugëve para se adresa të ekzistojë fsheh problemin e vërtetë.

Lexojeni dështimin në rendin që klienti e ekzekuton

VpnService.Builder i Android-it i mban dy konceptet të ndara: addAddress() vendos adresë në ndërfaqen që aplikacioni po ndërton, addRoute() shton një prefiks destinacioni, dhe establish() refuzon të krijojë ndërfaqen derisa të shtohet të paktën një adresë. Klienti OpenVPN e pasqyron profilin dhe opsionet që shtyn serveri pikërisht në ato thirrje, pra një lidhje që nuk analizon kurrë një adresë nuk mund ta ndërtojë fare ndërfaqen.

Kjo është arsyeja pse rreshti i regjistrit që po lexoni mund të përmendë një rrugë ndërsa shkaku qëndron një hap më parë. Klienti arrin fazën e rrugës vetëm pasi ndërfaqja ekziston; pa adresë, thirrja e rrugës dështon menjëherë ose nuk ekzekutohet kurrë. Kur regjistri thotë se nuk mund të shtojë rrugë, filloni me adresën dhe jo me sintaksën e rrugës.

Kontrolli 1: a vendos serveri një adresë në përgjigje?

Për një shërbim OpenVPN të rrugëzuar adresa vjen nga grupi i serverit ose nga një caktim për klient, dhe topologjia vendos formën e saj. Në një server OpenVPN 2.4 ose më të ri, një shërbim me topologji nënrrjete duket kështu:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Me atë formë serveri shtyn diçka si ifconfig 10.8.0.6 255.255.255.0. Një instalim më i vjetër me topology net30 shtyn në vend të kësaj një adresë kolegu, për shembull ifconfig 10.8.0.6 10.8.0.5, pra një profil i zhvendosur midis dy modeleve mund të duket i saktë ndërsa mban maskën e gabuar të rrjetit.

Kërkoni në regjistrin e lidhjes së klientit grupin e opsioneve të shtyra. Nëse nuk përmban asnjë rresht ifconfig, serveri nuk ka dërguar kurrë adresë ose klienti e ka refuzuar opsionin. Në një server që përdor client-config-dir, skedari i emërtuar sipas common name të certifikatës duhet të ekzistojë dhe të mbajë caktimin:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontrolli 2: a e mban klienti adresën që mori?

Një filtër shumë i gjerë është shkaku i dytë i zakonshëm. pull-filter ekziston në OpenVPN 2.4 e më të re, dhe kur disa filtra përputhen me të njëjtin opsion fiton i fundit që përputhet, pra një catch-all në fund e heq adresën pa gabim:

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

Ngushtoni filtrin në opsionin nga i cili vërtet doni të hiqni qafe dhe lëreni adresën të qetë:

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

Këshilla për të fikur të gjitha pull-të vjen zakonisht nga dikush që do të heqë qafe një rrugë të vetme. route-nopull është çelësi më i ngushtë: mban ifconfig dhe opsionet e tjera të shtyra ndërsa refuzon rrugët e shtyra dhe opsionet e tipit DHCP. Përdoreni kur kjo është vërtet ajo që dëshironi, dhe përgjigjuni pyetjes së adresës veçmas.

Kontrolli 3: a është adresa e jotja për ta shkruar?

Adresimi manual është i ligjshëm vetëm kur operatori jua jep vlerën. Nëse shkruani një vetë, duhet të vijë nga nënrrjeti i klientit VPN, të jetë unik midis sesioneve aktive dhe të përputhet me topologjinë që ekzekuton serveri. Kopjimi i adresës së një ure desktopi ose i një hosti në LAN-in e largët dështon në të dyja anët: telefoni do të kërkonte një adresë që ekziston tashmë diku tjetër, dhe porta nuk do të kishte rrugë kthimi drejt saj.

Prefiksi i LAN-it të largët në një rrugë është destinacion, kurrë identiteti i telefonit. Një rrugë për 10.60.0.0/24 thotë arrije atë rrjet përmes tunelit; nuk thotë asgjë për atë se cilën adresë 10.60.0.x duhet të mbajë telefoni, dhe telefoni nuk duhet të mbajë asnjërën prej tyre. Caktimet statike i përkasin anës së serverit, ku nuk mund të përplasen me grupin dinamik.

Dy sesione në një identitet zbulojnë të njëjtin përplasje. Nëse i njëjti certifikatë lidhet dy herë dhe serveri shtyn një adresë fikse për të dyja, sesioni i dytë dublon të parin, dhe zgjidhja janë identitete të ndara ose caktime të ndara, jo një ndryshim në anën e klientit.

Kontrolli 4: a mban diçka tjetër vendin e tunelit?

Android lejon vetëm një shërbim VPN aktiv në të njëjtën kohë. Një aplikacion tjetër VPN, ose një zë VPN gjithmonë-aktiv i lënë i ndezur për një profil që nuk funksionon më, mund ta zërë atë vend para se klienti juaj OpenVPN të thërrasë establish(). Atëherë ndërfaqja nuk shfaqet kurrë edhe pse profili është i vlefshëm, pra shkëputni VPN-në tjetër, fikni cilësimin gjithmonë-aktiv dhe rilidhuni para se ta prekni profilin.

Një shërbim që këmbëngul në urëzimin Ethernet është rruga tjetër pa krye. Një aplikacion Android pa root mund të krijojë një tunel IP, jo një segment Ethernet të urëzuar, pra asnjë adresë që shkruani nuk do ta bëjë një server dev tap të funksionojë; operatori duhet të ofrojë një shërbim të rrugëzuar. Kur raportoni problemin, përfshini emrin dhe versionin e klientit, grupin e opsioneve të shtyra, topologjinë dhe hapin e saktë ku adresa duhej të shfaqej.

Nëse të katër kontrollet kalojnë dhe adresa është e pranishme, unike dhe e maskuar saktë, pyetja e rrugës bëhet e zakonshmja: cilat prefikse autorizon serveri dhe si duhet t'i kufizojë klienti. Shkruani adresën e tunelit, maskën e rrjetit dhe topologjinë para se të ndryshoni çdo gjë tjetër, sepse pikërisht këto tri vlera i duhen operatorit për t'i krahasuar me pamjen e serverit.