TAP vagy TUN? Android OpenVPN kliensek és hidas szerverek

Egy laptopon működő profil a telefonon elbukik. A kézenfekvő lépés egy szó módosítása a kliens konfigurációjában. Az a szó nem segít, mert a két vég nem ugyanarról a forgalomtípusról beszél.

A TAP Ethernet-kereteket szállít. A TUN IP-csomagokat szállít. Az Android VPN-alkalmazás IP-interfészt kap, ami a két elrendezés közül az egyiket lehetővé teszi, a másikat nem, függetlenül attól, mit mond a konfiguráció.

Az összehasonlítás rövid, de eldönti, hogy javíthatja-e a telefonon, vagy a szolgáltatást kell megváltoztatni.

Két alagúttípus eltérő hasznos teherrel

A TAP-interfész Ethernet-adapterként viselkedik. Kereteket szállít, tehát ARP-t, broadcastot és mindent, amit egy LAN az IP alatt szállít. Ez teszi lehetővé a hidat: az alagút kiterjeszt egy broadcast-tartományt, és a kliensek úgy viselkednek, mintha switchbe dugták volna őket.

A TUN-interfész a neki címzett IP-csomagokat szállítja. Nincs egyeztethető kapcsolati réteg, nincs ARP és nincs broadcast. Az útválasztás dönti el, mi kerül az alagútba, és a szerveroldali konfiguráció híd helyett alhálózatot használ.

Mindkét végnek meg kell egyeznie abban, melyiket csinálja. A dev tap dev tun-re cserélése az egyik oldalon nem alakítja át a szolgáltatást; olyan klienst eredményez, amely útválasztott alagutat vár, és olyan szervert, amely még mindig kereteket küld, és a kézfogás sikerülhet, miközben semmi használható nem halad át.

Mit ad valójában az Android az alkalmazásnak

A platform VpnService API-ja virtuális interfészt ad az alkalmazásnak IP-csomagokhoz, címekkel, útvonalakkal és MTU-val konfigurálva. Ebben az API-ban nincs Ethernet-adapter, és az alkalmazás nem tud kitalálni egyet.

Ezért dokumentál az OpenVPN Connect Androidon útválasztott TUN-kapcsolatokat, nem TAP-hidakat. Az Android GYIK a határ kliensoldali megfogalmazása, és megfelel a platform API-jának.

Root jogosultságú hálózati eszközök, egyedi firmware vagy kifejezett fordítási réteget megvalósító termék más elrendezések. A szokásos eset az, amelyre tervezni kell: egy alkalmazás, amely importálja a fájlját és normál felhasználóként fut, IP-interfésszel és semmivel alatta.

Hogyan néz ki, ha mégis megpróbálja

A kapcsolat általában létrejön. Ez teszi zavaróvá a hibát: a kliens kapcsolódottnak jelent, a szervernapló egy partnert mutat, és egyetlen alkalmazás sem működik.

A telefonhoz rendelt címre küldött forgalom nem érkezik meg, mert a szerver kereteket hidal egy olyan MAC-címre, amellyel a telefon soha nem rendelkezett. A broadcasttól függő felderítés üres marad. Ha a LAN a hídon keresztül DHCP-re támaszkodik, a telefon így nem kap bérletet, és a hídba kötött alhálózatban kézzel beállított cím sem hozza létre a hiányzó interfészt.

Egyes kliensek korábban, a profil importálásakor buknak el, amikor olyan eszköztípust látnak, amelyet nem tudnak megvalósítani. Mindkét viselkedés ugyanazt jelenti, és egyiket sem javítja útvonalak hozzáadása, a DNS módosítása vagy az alagút címterének bővítése.

Mit kell megváltoztatnia a szerveroldalnak

A javítás annak a dolga, aki a VPN-szolgáltatást üzemelteti, és általában hozzáadás, nem migráció. Indítson egy második OpenVPN-példányt útválasztott eszközzel, saját kliens-alhálózattal és olyan szerveroldali konfigurációval, amely címeket oszt ki és továbbítja a telefonoknak szükséges útvonalakat. A meglévő hidas példány továbbra is kiszolgálja azokat az eszközöket, amelyeknek valóban Ethernet kell.

Két részlet teszi ezt a gyakorlatban működőképessé. A LAN-nak visszaútvonalra van szüksége az új kliens-alhálózathoz, amely a VPN-gazdára mutat, különben a válaszok soha nem jönnek vissza. És az alagút gazdáján lévő tűzfálnak továbbítania kell az alagút-interfész és a LAN között, és ez az a lépés, amelyet a leggyakrabban kihagynak, amikor a gazdáról indított teszt sikerül.

Ha az üzemeltető nem tud szolgáltatást hozzáadni, a másik lehetőség egy eszköz, amely csatlakozni tud a hídhoz, tehát egy laptop vagy egy router, amely a telefon nevében jár el. Ez saját kezelési költségű kerülőmegoldás, nem Android-konfiguráció.

Az alkalmazásból döntsön, ne az alagútból

Kérdezze meg, mit kell a telefonnak valóban elérnie, majd térképezze fel. A név vagy cím szerint elérhető fájlmegosztás vagy intranet-oldal IP-követelmény, és egy útválasztott alagút kielégíti, ha a DNS feloldja a nevet és létezik az útvonal. A helyi broadcast-tartományt böngésző felderítőeszköz nem IP-követelmény, és semmilyen mennyiségű útválasztás nem tölti meg.

Ez a táblázat egyben az elküldendő kérés. Nevezze meg az alkalmazást, az általa használt címet vagy nevet, és hogy függ-e a felderítéstől. Az üzemeltető tud cselekedni e leírás alapján, amit senki nem tud olyan telefonnal, amely nem kapcsolódik.

Végül, tartsa meg a TAP-szolgáltatást azoknak az eszközöknek, amelyeknek szükségük van rá, ahelyett hogy minden klienstől LAN-adapter utánzását kérné. Két világos célú szolgáltatást könnyebb támogatni, mint egyet, amely mindenki számára félmunkát végez.