TAP czy TUN? Klienci OpenVPN na Androida i serwery z mostem

Profil, który działa na laptopie, zawodzi na telefonie. Oczywistym krokiem jest zmiana jednego słowa w konfiguracji klienta. To słowo nie pomoże, ponieważ oba końce nie mówią o tym samym rodzaju ruchu.

TAP przenosi ramki Ethernet. TUN przenosi pakiety IP. Aplikacja VPN na Androida otrzymuje interfejs IP, co czyni jeden z tych dwóch układów możliwym, a drugi nie, niezależnie od tego, co mówi konfiguracja.

Porównanie jest krótkie, ale decyduje, czy można to naprawić na telefonie, czy trzeba zmienić usługę.

Dwa typy tuneli z różnymi ładunkami

Interfejs TAP zachowuje się jak adapter Ethernet. Przenosi ramki, czyli ARP, rozgłaszanie i wszystko inne, co LAN przenosi poniżej IP. Właśnie to umożliwia mostkowanie: tunel rozszerza domenę rozgłaszania, a klienci zachowują się tak, jakby byli podłączeni do przełącznika.

Interfejs TUN przenosi pakiety IP zaadresowane do niego. Nie ma warstwy łącza do negocjacji, nie ma ARP i nie ma rozgłaszania. O tym, co wchodzi do tunelu, decyduje rutowanie, a konfiguracja po stronie serwera używa podsieci, a nie mostu.

Oba końce muszą się zgodzić, który z tych dwóch wariantów realizują. Zmiana dev tap na dev tun po jednej stronie nie konwertuje usługi; powstaje klient, który oczekuje rutowanego tunelu, i serwer, który nadal wysyła ramki, a uzgadnianie może się udać, podczas gdy nic użytecznego nie przechodzi.

Co Android naprawdę daje aplikacji

API VpnService platformy daje aplikacji wirtualny interfejs dla pakietów IP, skonfigurowany adresami, trasami i MTU. W tym API nie ma adaptera Ethernet i aplikacja nie może go wymyślić.

Dlatego OpenVPN Connect dokumentuje obsługę rutowanych połączeń TUN na Androidzie, a nie mostkowania TAP. FAQ Androida to oświadczenie strony klienta o tej granicy i odpowiada ono API platformy.

Narzędzia sieciowe z rootem, własne oprogramowanie układowe lub produkt z jawną warstwą tłumaczenia to inne układy. Zwykły przypadek to ten, wokół którego należy planować: aplikacja, która potrafi zaimportować plik i działać jako zwykły użytkownik, z interfejsem IP i niczym pod nim.

Jak to wygląda, gdy mimo wszystko spróbujesz

Połączenie zwykle się nawiązuje. Właśnie to sprawia, że błąd jest mylący: klient zgłasza połączenie, dziennik serwera pokazuje partnera, a żadna aplikacja nie działa.

Ruch adresowany na przypisany adres telefonu nie dociera, ponieważ serwer mostkuje ramki na adres MAC, którego telefon nigdy nie miał. Wykrywanie zależne od rozgłaszania pozostaje puste. Jeśli LAN opiera się na DHCP przez most, telefon nie uzyska w ten sposób dzierżawy, a ręcznie przypisany adres w podsieci z mostem nadal nie tworzy brakującego interfejsu.

Niektóre klienty zawodzą wcześniej, przy importie profilu, gdy widzą typ urządzenia, którego nie potrafią zaimplementować. Oba zachowania znaczą to samo i żadnego nie naprawia dodanie tras, zmiana DNS ani rozszerzenie zakresu adresów tunelu.

Co musi zmienić strona serwera

Poprawka należy do tego, kto obsługuje usługę VPN, i zwykle jest dodatkiem, a nie migracją. Uruchomić drugą instancję OpenVPN z rutowanym urządzeniem, własną podsiecią klientów oraz konfiguracją po stronie serwera, która przydziela adresy i wypycha trasy potrzebne telefonom. Istniejąca instancja z mostem nadal obsługuje urządzenia, które naprawdę potrzebują Ethernetu.

Dwa szczegóły czynią to praktycznie działającym. LAN potrzebuje trasy powrotnej dla nowej podsieci klientów, wskazującej na host VPN, inaczej odpowiedzi nigdy nie wrócą. A zapora na hoście tunelu musi przekazywać ruch między interfejsem tunelu a LAN, i to jest krok najczęściej pomijany, gdy test z samego hosta się udaje.

Jeśli operator nie może dodać usługi, alternatywą jest urządzenie, które może dołączyć do mostu, czyli laptop lub router działający w imieniu telefonu. To obejście z własnym kosztem zarządzania, a nie konfiguracja Androida.

Decyduj na podstawie aplikacji, nie tunelu

Zapytaj, do czego telefon naprawdę musi dotrzeć, a potem to zmapuj. Udział plików lub witryna intranetowa osiągalna po nazwie lub adresie to wymóg IP, a rutowany tunel spełnia go, gdy DNS rozwiąże nazwę i trasa istnieje. Narzędzie wykrywania przeglądające lokalną domenę rozgłaszania nie jest wymogiem IP i żadna ilość rutowania go nie wypełni.

Ta tabela jest także prośbą do wysłania. Nazwij aplikację, adres lub nazwę, której używa, oraz to, czy zależy od wykrywania. Operator może działać na podstawie tego opisu, czego nikt nie może zrobić z telefonem, który się nie łączy.

Na koniec, zachowaj usługę TAP dla urządzeń, które jej potrzebują, zamiast kazać każdemu klientowi naśladować adapter LAN. Dwoma usługami o jasnych celach łatwiej zarządzać niż jedną, która dla wszystkich działa połowicznie.