Android OpenVPN ez du biderik gehitzen tunel helbiderik gabe

Zure Android OpenVPN profilak ezin du biderik gehitu telefonoak ez duelako helbiderik interfaze birtualean, beraz ez dago bider batek seina dezakeen ezer. Bideek paketeak nora joan behar duten soilik erantzuten dute. Tunel helbideak telefonoa tunelaren barruan nor den erantzuten du, eta bezeroak bat eman behar du interfazea existitu ahal izateko. Joan beheko lau egiaztapenak ordenan eta gelditu lehen hutsegitean, helbidea existitu aurretik bideak editatzeak benetako arazoa ezkutatzen duelako.

Irakurri hutsegitea bezeroak exekutatzen duen ordenan

Androiden VpnService.Builder bi kontzeptuak bereizita mantentzen ditu: addAddress() aplikazioak eraikitzen ari den interfazean helbidea jartzen du, addRoute() helmugako aurrizkia gehitzen du, eta establish() interfazea sortzeari uko egiten dio gutxienez helbide bat gehitu arte. OpenVPN bezeroak profila eta zerbitzariak bidalitako aukerak deialdi horietan mapatzen ditu, beraz helbiderik inoiz analizatzen ez duen konexioak ezin du interfazea eraiki.

Horregatik irakurtzen ari zaren log lerroak bide bat aipa dezake arrazoia pauso bat lehenago dagoenean. Bezeroa bidearen fasera interfazea existitu ondoren iristen da; helbiderik gabe, bide deialdia berehala huts egiten du edo ez da inoiz exekutatzen. Logak biderik ezin duela gehitu esaten duenean, hasi helbidearekin eta ez bidearen sintaxiarekin.

1. egiaztapena: erantzunean helbidea jartzen al du zerbitzariak?

Bideratutako OpenVPN zerbitzu batean helbidea zerbitzariaren multzotik edo bezero bakoitzeko esleipenetik dator, eta topologiak zehazten du haren forma. OpenVPN 2.4 edo berriagoa den zerbitzarian, azpisare topologiadun zerbitzuak itxura hau du:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Forma horrekin zerbitzariak ifconfig 10.8.0.6 255.255.255.0 antzeko zerbait bidaltzen du. topology net30 instalazio zaharragoak pare helbidea bidaltzen du horren ordez, adibidez ifconfig 10.8.0.6 10.8.0.5, beraz bi ereduen artean mugitutako profilak zuzena dirudi baina sare-maskara okerra darama.

Bilatu bezeroaren konexio logean bidalitako aukera multzoa. ifconfig lerro bat ere ez badu, zerbitzariak ez zuen inoiz helbiderik bidali edo bezeroak aukera uko egin zion. client-config-dir erabiltzen duen zerbitzarian, ziurtagiriaren common name izena duen fitxategiak existitu behar du eta esleipena eduki:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

2. egiaztapena: jasotako helbidea gordetzen al du bezeroak?

Iragazki zabalegia da bigarren arrazoi ohikoa. pull-filter OpenVPN 2.4 eta berriagoetan dago, eta hainbat iragazkik aukera berarekin bat egiten dutenean azkena bat datorrena irabazten du, beraz amaieran utzitako catch-all batek helbidea kentzen du errorerik gabe:

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

Murriztu iragazkia benetan kendu nahi duzun aukerara eta utzi helbidea bakean:

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

Pull guztiak desaktibatzeko aholkua bide bakar bat kendu nahi duen norbaitengandik etorri ohi da. route-nopull etengailu estuagoa da: ifconfig eta gainerako bidalitako aukerak mantentzen ditu, bidalitako bideak eta DHCP estiloko aukerak baztertzen dituen bitartean. Erabili benetan hori nahi duzunean, eta erantzun helbidearen galderari bereizita.

3. egiaztapena: zurea al da helbidea idazteko?

Eskuzko helbideratzea legitiboa da operadoreak balioa ematen dizunean soilik. Zeuk idazten baduzu, VPN bezeroaren azpisaretik etorri behar du, aktibo dauden saioen artean bakarra izan eta zerbitzariak exekutatzen duen topologiarekin bat etorri. Mahaigaineko zubi edo urruneko LANeko ostalari baten helbidea kopiatzeak bi aldetan huts egiten du: telefonoak lekuan beste bat dagoen helbidea aldarrikatuko luke, eta atebideak ez luke hartarako itzulera biderik izango.

Bide batean urruneko LAN aurrizkia helmuga da, inoiz ez telefonoaren identitatea. 10.60.0.0/24 rako bideak dio sare horretara tunelaren bidez iristen dela; ez du esaten telefonoak zein 10.60.0.x helbide eduki beharko lukeen, eta telefonoak ez luke horietako bat bera ere eduki behar. Esleipen estatikoak zerbitzariaren aldean daude, non ezin duten multzo dinamikoarekin talka egin.

Identitate batean bi saioek talka bera erakusten dute. Ziurtagiri berak bi aldiz konektatzen badu eta zerbitzariak helbide finko bat bidaltzen badie biei, bigarren saioak lehena bikoizten du, eta konponbidea identitate bereiziak edo esleipen bereiziak dira, ez bezeroaren aldeko aldaketa.

4. egiaztapena: beste zerbait al dago tunelaren tokia hartzen?

Androidek VPN zerbitzu aktibo bakarra onartzen du aldi berean. Beste VPN aplikazio batek, edo jada funtzionatzen ez duen profil baterako piztuta utzitako always-on VPN sarrera batek, tarte hori har dezake zure OpenVPN bezeroak establish() deitu aurretik. Orduan interfazea ez da inoiz agertzen profila baliozkoa izan arren, beraz deskonektatu beste VPN-a, itzali always-on ezarpena eta konektatu berriro profila ukitu aurretik.

Ethernet zubiak eskatzen dituen zerbitzua beste kale itsua da. root gabeko Android aplikazio batek IP tunela sor dezake, ez zubitutako Ethernet segmentua, beraz idazten duzun edozein helbidek ez du dev tap zerbitzaria funtzionaraziko; operadoreak zerbitzu bideratua eskaini behar du. Arazoa jakinaraztean, sartu bezeroaren izena eta bertsioa, bidalitako aukera multzoa, topologia eta helbidea agertu behar zen urrats zehatza.

Lau egiaztapenek gainditzen badute eta helbidea badago, bakarra eta ondo maskaratua, bidearen galdera ohikoa bihurtzen da: zein aurrizki baimenduta dituen zerbitzariak eta nola mugatu behar dituen bezeroak. Idatzi tunel helbidea, sare-maskara eta topologia beste ezer aldatu aurretik, hiru balio horiek direlako operadoreak zerbitzariaren ikuspegiarekin alderatu behar dituenak.