TAP vai TUN? Androidin OpenVPN-asiakkaat ja sillatut palvelimet

Kannettavassa tietokoneessa toimiva profiili epäonnistuu puhelimessa. Ilmeinen askel on muuttaa yhtä sanaa asiakkaan kokoonpanossa. Se sana ei auta, koska kaksi päätä eivät puhu samasta liikennetyypistä.

TAP kuljettaa Ethernet-kehyksiä. TUN kuljettaa IP-paketteja. Androidin VPN-sovellukselle annetaan IP-rajapinta, mikä tekee toisesta järjestelystä mahdollisen ja toisesta mahdottoman riippumatta siitä, mitä kokoonpano sanoo.

Vertailu on lyhyt, mutta se ratkaisee, voitko korjata tämän puhelimessa vai täytyykö palvelua muuttaa.

Kaksi erilaista hyötykuormaa kuljettavaa tunnelityyppiä

TAP-rajapinta käyttäytyy kuin Ethernet-sovitin. Se kuljettaa kehyksiä, eli ARP:n, lähetyksen ja kaiken muun, mitä lähiverkko kuljettaa IP:n alapuolella. Juuri se tekee sillan mahdolliseksi: tunneli laajentaa lähetysaluetta ja asiakkaat käyttäytyvät kuin ne olisi kytketty kytkimeen.

TUN-rajapinta kuljettaa sille osoitettuja IP-paketteja. Neuvoteltavaa siirtokerrosta ei ole, ei ARP:a eikä lähetystä. Reititys päättää, mitä tunneliin tulee, ja palvelinpuolen kokoonpano käyttää aliverkkoa sillan sijaan.

Molempien päiden on sovittava, kumman niistä ne tekevät. dev tap:n vaihtaminen dev tun:ksi toisella puolella ei muunna palvelua; tuloksena on asiakas, joka odottaa reititettyä tunnelia, ja palvelin, joka lähettää yhä kehyksiä, ja kättely voi onnistua, vaikka mitään käyttökelpoista ei kulje läpi.

Mitä Android todella antaa sovellukselle

Alustan VpnService-rajapinta antaa sovellukselle virtuaalisen rajapinnan IP-paketeille, konfiguroituna osoitteilla, reiteillä ja MTU:lla. Siinä rajapinnassa ei ole Ethernet-sovitinta, eikä sovellus voi loihtia sellaista.

Siksi OpenVPN Connect dokumentoi tuen reititetyille TUN-yhteyksille Androidissa eikä TAP-silloille. Androidin UKK on asiakaspuolen lausuma tästä rajasta, ja se vastaa alustan rajapintaa.

Root-oikeuksilla toimivat verkkotyökalut, mukautettu laiteohjelmisto tai tuote, joka toteuttaa eksplisiittisen käännöskerroksen, ovat muita järjestelyjä. Tavallinen tapaus on se, jonka varaan kannattaa suunnitella: sovellus, joka voi tuoda tiedostosi ja toimia tavallisena käyttäjänä, IP-rajapinnalla ja ilman mitään sen alla.

Miltä se näyttää, kun yrität silti

Yhteys yleensä muodostuu. Juuri se tekee virheestä hämmentävän: asiakas ilmoittaa yhteydestä, palvelimen loki näyttää vastapuolen, eikä mikään sovellus toimi.

Puhelimelle osoitettuun osoitteeseen lähetetty liikenne ei saavu, koska palvelin sillaa kehyksiä MAC-osoitteeseen, jota puhelimella ei koskaan ollut. Lähetyksestä riippuvainen löytäminen jää tyhjäksi. Jos lähiverkko nojaa sillan yli DHCP:hen, puhelin ei saa vuokraa sitä kautta, eikä sillatussa aliverkossa käsin annettu osoite silti luo puuttuvaa rajapintaa.

Jotkut asiakkaat epäonnistuvat aiemmin, profiilin tuonnissa, kun ne näkevät laitetyypin, jota ne eivät voi toteuttaa. Kumpikin käytös tarkoittaa samaa, eikä kumpaakaan korjata lisäämällä reittejä, muuttamalla DNS:ää tai leventämällä tunnelin osoitealuetta.

Mitä palvelinpuolen on muutettava

Korjaus kuuluu VPN-palvelun ylläpitäjälle, ja se on yleensä lisäys eikä migraatio. Käynnistä toinen OpenVPN-instanssi reititetyllä laitteella, omalla asiakasaliverkolla ja palvelinpuolen kokoonpanolla, joka jakaa osoitteet ja työntää reitit, joita puhelimet tarvitsevat. Nykyinen sillattu instanssi palvelee edelleen laitteita, jotka todella tarvitsevat Ethernetiä.

Kaksi yksityiskohtaa tekee siitä käytännössä toimivan. Lähiverkko tarvitsee paluureitin uudelle asiakasaliverkolle VPN-isäntään osoittaen, muuten vastaukset eivät koskaan palaa. Ja tunnelin isännän palomuurin on välitettävä tunnelirajapinnan ja lähiverkon välillä, ja se on vaihe, joka useimmin unohdetaan, kun isännästä itsestään tehty testi onnistuu.

Jos operaattori ei voi lisätä palvelua, vaihtoehto on laite, joka voi liittyä siltaan, eli kannettava tietokone tai reititin, joka toimii puhelimen puolesta. Se on omat hallintakustannuksensa omaava kiertotie, ei Androidin kokoonpano.

Päätä sovelluksesta, älä tunnelista

Kysy, mihin puhelimen on todella päästävä, ja kartoita se sitten. Nimellä tai osoitteella saavutettava tiedostojako tai intranet-sivusto on IP-vaatimus, ja reititetty tunneli täyttää sen, kun DNS ratkaisee nimen ja reitti on olemassa. Paikallista lähetysaluetta selaava löytämistyökalu ei ole IP-vaatimus, eikä mikään määrä reititystä täytä sitä.

Tuo taulukko on myös lähetettävä pyyntö. Nimeä sovellus, sen käyttämä osoite tai nimi ja se, riippuuko se löytämisestä. Operaattori voi toimia tuon kuvauksen perusteella, mitä kukaan ei voi tehdä puhelimella, joka ei yhdistä.

Lopuksi, pidä TAP-palvelu niille laitteille, jotka sitä tarvitsevat, sen sijaan että pakottaisit jokaisen asiakkaan matkimaan lähiverkkosovitinta. Kahta selkeän tarkoituksen palvelua on helpompi tukea kuin yhtä, joka toimii puolittain kaikille.