TAP или TUN? OpenVPN клиенти за Android и премостени сервери
TAP пренесува Ethernet рамки, TUN пренесува IP пакети, а Android апликацијата добива само вториот вид. Споредете ги двете и потоа поправете ја серверската страна.
Профил што работи на преносен сметач не успева на телефонот. Очигледниот чекор е да се смени еден збор во конфигурацијата на клиентот. Тој збор нема да помогне, бидејќи двата краја не зборуваат за ист вид сообраќај.
TAP пренесува Ethernet рамки. TUN пренесува IP пакети. На Android VPN апликација ѝ се дава IP интерфејс, што го прави едниот од двата распореди возможен, а другиот не, без оглед што вели конфигурацијата.
Споредбата е кратка, но таа одлучува дали можете да го поправите на телефонот или мора да ја смените услугата.
Два вида тунели со различен носив товар
TAP интерфејсот се однесува како Ethernet адаптер. Пренесува рамки, односно ARP, емитување и сето друго што LAN пренесува под IP. Токму тоа овозможува премостување: тунелот го проширува доменот на емитување и клиентите се однесуваат како да се приклучени на комутатор.
TUN интерфејсот ги пренесува IP пакетите упатени до него. Нема слој на врска за договарање, нема ARP и нема емитување. Рутирањето одлучува што влегува во тунелот, а конфигурацијата на серверската страна користи подмрежа наместо мост.
Двата краја мора да се согласат кое од тие две го прават. Менувањето на dev tap во dev tun на едната страна не ја претвора услугата; се добива клиент што очекува рутиран тунел и сервер што уште праќа рамки, а ракувањето може да успее додека ништо употребливо не поминува.
Што Android навистина му дава на апликацијата
API-то VpnService на платформата на апликацијата ѝ дава виртуелен интерфејс за IP пакети, конфигуриран со адреси, рути и MTU. Во тоа API нема Ethernet адаптер, а апликацијата не може да измисли еден.
Затоа OpenVPN Connect документира поддршка за рутирани TUN врски на Android, а не за TAP премостување. Android ЧПП е изјавата на клиентската страна за таа граница и се совпаѓа со API-то на платформата.
Мрежни алатки со root права, прилагоден фирмвер или производ што спроведува јасен слој за преведување се други распореди. Обичниот случај е оној околу кој треба да се планира: апликација што може да ја увезе вашата датотека и да работи како обичен корисник, со IP интерфејс и ништо под него.
Како изгледа кога сепак ќе се обидете
Врската обично се воспоставува. Токму тоа го прави неуспехот збунувачки: клиентот известува за поврзаност, серверскиот дневник покажува партнер, а ниту една апликација не работи.
Сообраќајот упатен до доделената адреса на телефонот не пристигнува, бидејќи серверот ги премостува рамките до MAC адреса што телефонот никогаш ја немал. Откривањето зависно од емитување останува празно. Ако LAN се потпира на DHCP преку мостот, телефонот така нема да добие закуп, а рачно доделената адреса во премостената подмрежа сепак не го создава интерфејсот што недостасува.
Некои клиенти не успеваат порано, при увезување на профилот, кога ќе видат тип на уред што не можат да го спроведат. Двете однесувања значат исто, и ниту едно не се поправа со додавање рути, менување DNS или проширување на опсегот на адреси на тунелот.
Што мора да смени серверската страна
Поправката ѝ припаѓа на онаа страна што управува со VPN услугата и обично е дополнување, а не миграција. Стартувајте втор пример на OpenVPN со рутиран уред, сопствена клиентска подмрежа и конфигурација на серверската страна што доделува адреси и ги праќа рутите што им се потребни на телефоните. Постојниот премостен пример продолжува да ги опслужува уредите на кои навистина им треба Ethernet.
Два детали го прават тоа практично изводливо. На LAN му треба повратна рута за новата клиентска подмрежа, насочена кон VPN домаќинот, инаку одговорите никогаш нема да се вратат. И огнениот ѕид на домаќинот на тунелот мора да проследува меѓу интерфејсот на тунелот и LAN, а тоа е чекорот што најчесто се пропушта кога тестот од самиот домаќин успева.
Ако операторот не може да додаде услуга, алтернативата е уред што може да се приклучи на мостот, односно преносен сметач или рутер што дејствува во името на телефонот. Тоа е заобиколно решение со сопствен трошок за управување, не е Android конфигурација.
Одлучете од апликацијата, не од тунелот
Прашајте до што телефонот навистина треба да стигне, потоа мапирајте го. Споделување датотеки или интранет страница достапна по име или адреса е IP барање, и рутиран тунел го задоволува откако DNS ќе го реши името и рутата постои. Алатка за откривање што го прелистува локалниот домен на емитување не е IP барање, и никакво рутирање нема да го исполни.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
Таа табела е и барањето што се праќа. Наведете ја апликацијата, адресата или името што го користи и дали зависи од откривање. Операторот може да дејствува врз основа на тој опис, што никој не може со телефон што не се поврзува.
Конечно, задржете ја TAP услугата за уредите на кои им треба, наместо да терате секој клиент да имитира LAN адаптер. Две услуги со јасни цели полесно се поддржуваат од една што половина работи за сите.