Android OpenVPN ne aldonas itineron sen tunela adreso

OpenVPN-klientoj en Android ne povas aldoni itinerojn ĝis la telefono havas tunelan adreson. Kontrolu, kiu asignas ĝin, kiuj pull-filtroj forĵetas ĝin, kaj kiam vi mem tajpu unu.

Via Android-OpenVPN-profilo malsukcesas aldoni itineron ĉar la telefono havas neniun adreson sur la virtuala interfaco, do nenio ekzistas, al kiu itinero povus montri. Itineroj respondas nur al la demando, kien paketoj iru. La tunela adreso respondas, kiu estas la telefono interne de la tunelo, kaj la kliento devas provizi unu antaŭ ol la interfaco povas ekzisti. Trairu la kvar kontrolojn sube laŭ ordo kaj haltu ĉe la unua malsukceso, ĉar redakti itinerojn antaŭ ol la adreso ekzistas kaŝas la veran problemon.

Legu la malsukceson laŭ la ordo, en kiu la kliento plenumas ĝin

La VpnService.Builder de Android tenas la du konceptojn apartaj: addAddress() metas adreson sur la interfacon, kiun la apo konstruas, addRoute() aldonas celan prefikson, kaj establish() rifuzas krei la interfacon ĝis almenaŭ unu adreso estas aldonita. OpenVPN-kliento mapas la profilon kaj la opciojn puŝitajn de la servilo ekzakte al tiuj alvokoj, do konekto, kiu neniam analizas adreson, tute ne povas konstrui la interfacon.

Tial la protokola linio, kiun vi legas, povas nomi itineron dum la kaŭzo kuŝas unu paŝon pli frue. La kliento atingas la itineran etapon nur post kiam la interfaco ekzistas; sen adreso la itinera alvoko tuj malsukcesas aŭ neniam ruliĝas. Kiam la protokolo diras, ke ĝi ne povas aldoni itineron, komencu per la adreso anstataŭ per la itinera sintakso.

Kontrolo 1: ĉu la servilo metas adreson en la respondon?

Por itinera OpenVPN-servo la adreso venas el la servila baseno aŭ el po-klienta atribuo, kaj la topologio decidas ĝian formon. Sur servilo OpenVPN 2.4 aŭ pli nova, subret-topologia servo aspektas tiel:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Kun tiu formo la servilo puŝas ion kiel ifconfig 10.8.0.6 255.255.255.0. Pli malnova topology net30-instalaĵo puŝas anstataŭe samtavolan adreson, ekzemple ifconfig 10.8.0.6 10.8.0.5, do profilo translokigita inter la du modeloj povas ŝajni ĝusta dum ĝi portas la malĝustan retmaskon.

Serĉu en la konekta protokolo de la kliento la puŝitan opciaron. Se ĝi tute ne enhavas linion ifconfig, la servilo neniam sendis adreson aŭ la kliento rifuzis la opcion. Sur servilo, kiu uzas client-config-dir, la dosiero nomita laŭ la komuna nomo de la atestilo devas ekzisti kaj porti la atribuon:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Kontrolo 2: ĉu la kliento konservas la adreson, kiun ĝi ricevis?

Tro larĝa filtro estas la dua kutima kaŭzo. pull-filter ekzistas en OpenVPN 2.4 kaj pli nova, kaj kiam pluraj filtroj kongruas kun la sama opcio, la lasta kongrua venkas, do fina kaptilo forigas la adreson sen eraro:

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

Mallarĝigu la filtron al la opcio, kiun vi vere volas forigi, kaj lasu la adreson trankvila:

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

Konsilo malŝalti ĉiujn puŝojn kutime venas de iu, kiu volas forigi unu solan itineron. route-nopull estas la pli mallarĝa ŝaltilo: ĝi konservas ifconfig kaj la aliajn puŝitajn opciojn dum ĝi malakceptas puŝitajn itinerojn kaj DHCP-similajn opciojn. Uzu ĝin, kiam tio vere estas via celo, kaj respondu la adresan demandon aparte.

Kontrolo 3: ĉu la adreso estas via por tajpi?

Manuala adresado estas laŭleĝa nur kiam la administranto donas al vi la valoron. Se vi tajpas unu mem, ĝi devas veni el la klienta subreto de la VPN, esti unika inter aktivaj sesioj kaj kongrui kun la topologio, kiun la servilo rulas. Kopii la adreson de labortabla ponto aŭ de gastiganto en la fora LAN malsukcesas ambaŭflanke: la telefono postulus adreson, kiu jam ekzistas aliloke, kaj la enirejo havus neniun revenan vojon al ĝi.

La fora LAN-prefikso en itinero estas celo, neniam la identeco de la telefono. Itinero por 10.60.0.0/24 diras atingi tiun reton tra la tunelo; ĝi diras nenion pri tio, kiun adreson 10.60.0.x la telefono devus teni, kaj la telefono tenu neniun el ili. Statikaj atribuoj apartenas al la servila flanko, kie ili ne povas kolizii kun la dinamika baseno.

Du sesioj sur unu identeco malkaŝas la saman kolizion. Se la sama atestilo konektiĝas dufoje kaj la servilo puŝas unu fiksan adreson al ambaŭ, la dua sesio duobligas la unuan, kaj apartaj identecoj aŭ apartaj atribuoj estas la solvo anstataŭ klientflanka redakto.

Kontrolo 4: ĉu io alia okupas la tunelan lokon?

Android permesas unu aktivan VPN-servon samtempe. Alia VPN-apo, aŭ always-on VPN-ero lasita ŝaltita por profilo, kiu ne plu funkcias, povas preni tiun lokon antaŭ ol via OpenVPN-kliento alvokas establish(). Tiam la interfaco neniam aperas, kvankam la profilo validas, do malkonektu la alian VPN, malŝaltu la always-on-agordon kaj rekonektu antaŭ ol vi tuŝos la profilon.

Servo, kiu insistas pri Ethernet-pontado, estas la alia sakstrato. Ne-radika Android-apo povas krei IP-tunelon, ne pontitan Ethernet-segmenton, do neniu adreso, kiun vi tajpas, igos dev tap-servilon funkcii; la administranto devas proponi itineran servon. Kiam vi raportas la problemon, inkluzivu la nomon kaj version de la kliento, la puŝitan opciaron, la topologion kaj la ĝustan paŝon, kie la adreso devintus aperi.

Se ĉiuj kvar kontroloj pasas kaj la adreso ĉeestas, unika kaj ĝuste maskita, la itinera demando fariĝas la ordinara: kiujn prefiksojn la servilo rajtigas kaj kiel la kliento limigu ilin. Notu la tunelan adreson, ĝian retmaskon kaj la topologion antaŭ ol vi ŝanĝos ion alian, ĉar tiuj tri valoroj estas tio, kion la administranto bezonas por kompari kun la servila vido.

Rilataj artikoloj