Androidin OpenVPN ei lisää reittiä ilman tunneliosoitetta

Androidin OpenVPN-profiilisi ei lisää reittiä, koska puhelimella ei ole osoitetta virtuaaliliittymässä, joten reitillä ei ole mitään mihin osoittaa. Reitit vastaavat vain siihen, minne paketit menevät. Tunneliosoite vastaa siihen, kuka puhelin on tunnelin sisällä, ja asiakasohjelman on annettava sellainen ennen kuin liittymä voi syntyä. Käy alla olevat neljä tarkistusta järjestyksessä ja pysähdy ensimmäiseen virheeseen, sillä reittien muokkaaminen ennen osoitteen olemassaoloa kätkee varsinaisen ongelman.

Lue virhe siinä järjestyksessä, jossa asiakasohjelma sen suorittaa

Androidin VpnService.Builder pitää kaksi käsitettä erillään: addAddress() asettaa osoitteen liittymään, jota sovellus rakentaa, addRoute() lisää kohdeprefiksin ja establish() kieltäytyy luomasta liittymää, kunnes vähintään yksi osoite on lisätty. OpenVPN-asiakasohjelma kuvaa profiilin ja palvelimen työntämät valinnat täsmälleen noihin kutsuihin, joten yhteys, joka ei koskaan jäsennä osoitetta, ei voi rakentaa liittymää lainkaan.

Siksi lukemasi lokirivi voi nimetä reitin, vaikka syy on yksi askel aiemmin. Asiakasohjelma saavuttaa reittivaiheen vain, kun liittymä on olemassa; ilman osoitetta reittikutsu epäonnistuu heti tai ei koskaan suoritu. Kun loki sanoo, ettei reittiä voi lisätä, aloita osoitteesta äläkä reitin syntaksista.

Tarkistus 1: laittaako palvelin osoitteen vastaukseen?

Reititetyssä OpenVPN-palvelussa osoite tulee palvelimen altaasta tai asiakaskohtaisesta määrityksestä, ja topologia päättää sen muodon. OpenVPN 2.4 tai uudemmassa palvelimessa aliverkkotopologian palvelu näyttää tältä:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Tällä muodolla palvelin työntää jotakin ifconfig 10.8.0.6 255.255.255.0 kaltaista. Vanhempi topology net30-käyttöönotto työntää sen sijaan vertaisosoitteen, esimerkiksi ifconfig 10.8.0.6 10.8.0.5, joten kahden mallin välillä siirretty profiili voi näyttää oikealta mutta kantaa väärää verkkopeitettä.

Etsi asiakasohjelman yhteyslokista työnnetty valintajoukko. Jos siinä ei ole lainkaan riviä ifconfig, palvelin ei koskaan lähettänyt osoitetta tai asiakasohjelma hylkäsi valinnan. Palvelimessa, joka käyttää client-config-dir, sertifikaatin common namen mukaan nimetyn tiedoston on oltava olemassa ja sisällettävä määritys:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Tarkistus 2: säilyttääkö asiakasohjelma saamansa osoitteen?

Liian laaja suodatin on toinen tavallinen syy. pull-filter on olemassa OpenVPN 2.4:ssä ja uudemmissa, ja kun useat suodattimet täsmäävät samaan valintaan, viimeksi täsmäävä voittaa, joten loppuun jätetty kaiken kattava suodatin poistaa osoitteen ilman virhettä:

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

Kavenna suodatin valintaan, jonka todella haluat pois, ja jätä osoite rauhaan:

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

Neuvo kytkeä kaikki pullit pois tulee yleensä joltakulta, joka haluaa eroon yhdestä ainoasta reitistä. route-nopull on kapeampi kytkin: se pitää ifconfigin ja muut työnnetyt valinnat mutta hylkää työnnetyt reitit ja DHCP-tyyppiset valinnat. Käytä sitä, kun se on todella tarkoituksesi, ja vastaa osoite-kysymykseen erikseen.

Tarkistus 3: onko osoite sinun kirjoitettavasi?

Manuaalinen osoitteistus on perusteltua vain, kun operaattori antaa arvon sinulle. Jos kirjoitat sen itse, sen on tultava VPN-asiakasohjelman aliverkosta, oltava ainutlaatuinen aktiivisten istuntojen joukossa ja vastattava topologiaa, jota palvelin ajaa. Työpöytäsillan tai etä-LANin isäntäkoneen osoitteen kopiointi epäonnistuu molemmilla perusteilla: puhelin vaatisi osoitteen, joka on jo olemassa muualla, eikä yhdyskäytävällä olisi paluureittiä siihen.

Etä-LANin prefiksi reitissä on kohde, ei koskaan puhelimen identiteetti. Reitti 10.60.0.0/24 kohteelle sanoo, että verkkoon pääsee tunnelin kautta; se ei sano mitään siitä, mikä 10.60.0.x-osoite puhelimella pitäisi olla, eikä puhelimella pitäisi olla yhtään niistä. Staattiset määritykset kuuluvat palvelinpuolelle, missä ne eivät voi törmätä dynaamiseen altaaseen.

Kaksi istuntoa yhdellä identiteetillä paljastaa saman törmäyksen. Jos sama sertifikaatti yhdistää kahdesti ja palvelin työntää yhden kiinteän osoitteen molemmille, toinen istunto monistaa ensimmäisen, ja korjaus on erilliset identiteetit tai erilliset määritykset eikä asiakaspuolen muokkaus.

Tarkistus 4: pitääkö jokin muu tunnelipaikkaa?

Android sallii vain yhden aktiivisen VPN-palvelun kerrallaan. Toinen VPN-sovellus tai aina päällä oleva VPN-merkintä, joka on jätetty päälle profiilille, joka ei enää toimi, voi viedä paikan ennen kuin OpenVPN-asiakasohjelmasi kutsuu establish(). Silloin liittymä ei koskaan ilmesty, vaikka profiili olisi kelvollinen, joten katkaise toinen VPN, kytke aina päällä -asetus pois ja yhdistä uudelleen ennen kuin kosket profiiliin.

Palvelu, joka vaatii Ethernet-sillan, on toinen umpikuja. Ilman rootia toimiva Android-sovellus voi luoda IP-tunnelin, ei sillattua Ethernet-segmenttiä, joten mikään kirjoittamasi osoite ei saa dev tap-palvelinta toimimaan; operaattorin on tarjottava reititetty palvelu. Kun raportoit ongelman, liitä mukaan asiakasohjelman nimi ja versio, työnnetty valintajoukko, topologia ja se täsmällinen vaihe, jossa osoitteen olisi pitänyt ilmestyä.

Jos kaikki neljä tarkistusta menevät läpi ja osoite on olemassa, ainutlaatuinen ja oikein peitetty, reittikysymyksestä tulee tavallinen: mitkä prefiksit palvelin valtuuttaa ja miten asiakasohjelman pitäisi rajata ne. Kirjoita tunneliosoite, sen verkkopeite ja topologia muistiin ennen kuin muutat mitään muuta, sillä juuri nuo kolme arvoa operaattori tarvitsee vertailtavaksi palvelimen näkymään.