Профіль, які працуе на ноўтбуку, не працуе на тэлефоне. Відавочны крок — змяніць адно слова ў канфігурацыі кліента. Гэтае слова не дапаможа, бо два бакі гавораць не пра адзін і той жа тып трафіку.

TAP перадае кадры Ethernet. TUN перадае IP-пакеты. Праграме VPN на Android даецца 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. FAQ па Android — гэта заява на баку кліента пра гэтую мяжу, і яна адпавядае API платформы.

Інструменты сеткі з root-правамі, уласная прашыўка або прадукт з яўным пластом пераўтварэння — гэта іншыя варыянты. Звычайны выпадак — той, вакол якога варта планаваць: праграма, якая можа імпартаваць ваш файл і працаваць як звычайны карыстальнік, з IP-інтэрфейсам і нічога пад ім.

Як гэта выглядае, калі вы ўсё ж паспрабуеце

Злучэнне звычайна ўстанаўліваецца. Менавіта гэта робіць збой заблытаным: кліент паведамляе пра злучэнне, журнал сервера паказвае партнёра, а ніводная праграма не працуе.

Трафік, накіраваны на прызначаны адрас тэлефона, не даходзіць, бо сервер мастуе кадры на MAC-адрас, якога ў тэлефона ніколі не было. Заснаванае на шырокавяшчальных пакетах выяўленне застаецца пустым. Калі LAN разлічвае на DHCP праз мост, тэлефон не атрымае арэнду такім шляхам, а прызначаны ўручную адрас у маставанай падсетцы ўсё роўна не стварае адсутны інтэрфейс.

Некаторыя кліенты здаюцца раней, пры імпарце профілю, калі бачаць тып прылады, які не могуць рэалізаваць. Любыя з гэтых паводзін азначаюць адно і тое ж, і ні адно з іх не выпраўляецца даданнем маршрутаў, зменай DNS ці пашырэннем дыяпазону адрасоў тунеля.

Што павінен змяніць бок сервера

Выпраўленне належыць таму, хто кіруе сэрвісам VPN, і звычайна яно дапаўняльнае, а не міграцыйнае. Запусціце другі асобнік OpenVPN з маршрутызаванай прыладай, уласнай падсеткай кліентаў і канфігурацыяй на баку сервера, якая прызначае адрасы і перадае маршруты, патрэбныя тэлефонам. Існуючы маставаны асобнік працягвае абслугоўваць прылады, якім сапраўды патрэбны Ethernet.

Дзве дэталі робяць гэта практычна працаздольным. LAN патрэбны зваротны маршрут для новай падсеткі кліентаў, які паказвае на хост VPN, інакш адказы ніколі не вернуцца. І міжсеткавы экран на хосце тунеля павінен перасылаць паміж інтэрфейсам тунеля і LAN — гэта той крок, які часцей за ўсё прапускаюць, калі тэст з самога хоста ўдаецца.

Калі аператар не можа дадаць сэрвіс, альтэрнатыва — прылада, якая можа далучыцца да моста, гэта значыць ноўтбук або маршрутызатар, які дзейнічае ад імя тэлефона. Гэта абыходзік з уласнымі выдаткамі на кіраванне, а не канфігурацыя Android.

Вырашайце зыходзячы з праграмы, а не з тунеля

Спытайце, да чаго тэлефон насамрэч павінен дабрацца, потым адлюструйце гэта. Агульны доступ да файлаў або сайт інтранэта, дасяжныя па імі або адрасе, — гэта патрабаванне IP, і маршрутызаваны тунель задавальняе яго, калі DNS развяжа імя і маршрут існуе. Інструмент выяўлення, які праглядае лакальны шырокавяшчальны дамен, не з’яўляецца патрабаваннем IP, і ніякая колькасць маршрутызацыі яго не запоўніць.

RequirementTunnel that satisfies it
File server or intranet by hostnameRouted TUN, with working DNS
Broadcast or ARP-based discoveryEthernet bridging, so not an ordinary Android client
Multicast deliveryBridging or an explicit multicast relay
One application to one addressRouted TUN, narrowest possible route

Гэтая табліца — таксама запыт, які трэба адправіць. Назавіце праграму, адрас або імя, якія яна выкарыстоўвае, і ці залежыць яна ад выяўлення. Аператар можа дзейнічаць паводле такога апісання, а вось паводле тэлефона, які не падключаецца, не можа ніхто.

Нарэшце, пакіньце сэрвіс TAP для прыладаў, якім ён патрэбны, замест таго каб кожны кліент імітаваў адаптар LAN. Два сэрвісы з яснымі мэтамі прасцей падтрымліваць, чым адзін, які працуе напалову для ўсіх.

Падобныя артыкулы