Android-OpenVPN voeg nie roete by sonder tunadres nie

Jou Android OpenVPN-profiel voeg nie roete by nie, want die foon het geen adres op die virtuele koppelvlak nie, en dan is daar niks waarheen die roete kan wys. Roetes sê net waarheen pakkette moet gaan. Die tunadres sê wie die foon in die tonnel is, en die kliënt moet een gee voordat die koppelvlak kan bestaan. Gaan die vier kontroles hier onder in volgorde deur en stop by die eerste fout, want roetes wysig voordat die adres daar is, verberg die werklike probleem.

Lees die fout in die volgorde waarin die kliënt dit uitvoer

Android se VpnService.Builder hou die twee begrippe apart: addAddress() sit adres op die koppelvlak wat die app bou, addRoute() voeg bestemmingvoorvoegsel by, en establish() weier om die koppelvlak te skep tot minstens een adres bygevoeg is. OpenVPN-kliënt beeld profiel en gepushte opsies op presies daardie oproepe af, so verbinding sonder adres kan die koppelvlak glad nie bou nie.

Daarom noem die logreël wat jy lees miskien roete terwyl die oorsaak een stap vroeër lê. Kliënt bereik roete eers wanneer koppelvlak bestaan; sonder adres misluk oproep dadelik of loop nooit. Wanneer log sê dit kan nie roete byvoeg nie, begin by adres en nie by roetesintaks nie.

Kontrole 1: sit die bediener adres in die antwoord?

By geroteerde OpenVPN-diens kom adres uit bedienerpoel of uit toewysing per kliënt, en topologie bepaal vorm. Op OpenVPN 2.4 of later bediener met subnet-topologie lyk dit so:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Met daardie vorm push bediener iets soos ifconfig 10.8.0.6 255.255.255.0. Ouer topology net30-ontplooiing push peeradres, byvoorbeeld ifconfig 10.8.0.6 10.8.0.5, so profiel wat tussen modelle geskuif is kan korrek lyk maar verkeerde netmasker dra.

Soek in kliënt se verbindingslog na gepushte opsies. As daar geen ifconfig-reël is nie, het bediener nooit adres gestuur of kliënt het opsie geweier. Op bediener met client-config-dir moet lêer vernoem na common name in sertifikaat bestaan en toewysing bevat:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontrole 2: hou die kliënt die adres wat gegee is?

Te wye filter is tweede algemene oorsaak. pull-filter bestaan sedert OpenVPN 2.4, en as verskeie filters op dieselfde opsie pas, wen die laaste, so alles-vanger verwyder adres sonder fout:

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

Maak filter smaller tot opsie wat jy regtig kwyt wil wees en los adres alleen:

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

Raad om alle pulls af te skakel kom gewoonlik van iemand wat een roete wil wegkry. route-nopull is smaller skakelaar: dit hou ifconfig en ander gepushte opsies en weier net gepushte roetes en DHCP-opsies. Gebruik dit wanneer dit werklik is wat jy wil, en antwoord adresvraag apart.

Kontrole 3: is die adres joune om te tik?

Handmatige adressering is net regmatig wanneer operateur waarde gee. Tik jy self een, moet dit uit VPN-kliëntsubnet kom, uniek onder aktiewe sessies wees en by topologie pas. Adres van lessenaar-brug of gasheer op afgeleë LAN kopieer faal op beide punte: foon eis adres wat elders bestaan, en gateway het geen terugpad nie.

Afgeleë LAN-voorvoegsel in roete is bestemming, nooit foon se identiteit nie. Roete vir 10.60.0.0/24 sê bereik daardie netwerk deur tonnel; dit sê niks oor watter 10.60.0.x-adres foon moet hê nie, en foon moet geen daarvan hê nie. Statiese toewysings hoort bedienerkant, waar hulle nie met dinamiese poel bots nie.

Twee sessies op een identiteit wys dieselfde botsing. As dieselfde sertifikaat twee keer verbind en bediener push een vaste adres na albei, dupliseer tweede sessie eerste, en aparte identiteite of toewysings is die oplossing, nie kliëntkant-wysiging nie.

Kontrole 4: hou iets anders die tonnelplek?

Android laat een aktiewe VPN-diens op keer. Ander VPN-app of always-on-inskrywing vir profiel wat nie meer werk nie kan plek neem voordat jou OpenVPN-kliënt establish() roep. Dan verskyn koppelvlak nooit al is profiel geldig, so ontkoppel ander VPN, skakel always-on af en verbind weer voordat jy profiel raak.

Diens wat op Ethernet-bridging aandring is ander doodloop. Android-app sonder root kan IP-tonnel maak, nie gebrugde Ethernet-segment nie, so geen adres wat jy tik maak dev tap-bediener werkend nie; operateur moet geroteerde diens bied. Rapporteer probleem met kliëntnaam en weergawe, gepushte opsies, topologie en presiese stap waar adres moes verskyn.

As al vier kontroles slaag en adres teenwoordig, uniek en reg gemaskeer is, word roetevraag gewone een: watter voorvoegsels bediener magtig en hoe kliënt dit moet beperk. Skryf tunadres, netmasker en topologie neer voordat jy iets anders verander, want daardie drie waardes is wat operateur teen bedieneraansig vergelyk.