Android OpenVPN: дадаць прыватны маршрут без root на тэлефоне

Патрэбна яшчэ адна прыватная падсетка, скажам 10.60.0.0/24, якой у профілі пакуль няма. На ноўтбуку вы дадаяце маршрут і ідзяце далей. На Android VPN — гэта праграма, прылада tun належыць гэтай праграме, і табліцы маршрутызацыі, якую можна правіць без root, няма. Маршрут павінен існаваць, але ён трапляе ў профіль, які загружае кліент, і працуе толькі калі іншы бок згодны. Далей — праўка, перападключэнне, бок сервера і адкат.

Перад праўкай: што маршрут можа і чаго не можа

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

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

Правіце профіль, які кліент сапраўды загружае

Для сумяшчальнага кліента, які імпартуе звычайны тэкст опцый OpenVPN, дадатак — адзін радок:

route 10.60.0.0 255.255.255.0

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

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

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

Перападключыцеся і праверце на прыладзе

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

Правярайце адрасат па адрасе, а не па імені. Праверка TCP на вядомы порт сэрвісу інфарматыўнейшая за ping, бо шматлікія хасты адказваюць на ICMP, пакуль порт сэрвісу фільтруецца. Калі адрас адказвае, а імя не, у вас пытанне рэзалвера, а не маршрутызацыі, і наступны раздзел не для вас.

Тут жа дзве праверкі ахопу. Per-app VPN азначае, што маршрут адраса можа быць, а праграма, якой вы тэстуеце, — па-за ўключаным наборам, таму тэстуйце праграмай, якая сапраўды ўнутры. Прэфікс IPv4 нічога не кажа пра шлях IPv6; калі сэрвіс двухстэкавы, дадайце адпаведны маршрут IPv6 або чакайце, што кліент абярэ шлях, якога вы не мелі на ўвазе.

Адзін негатыўны вынік варта распазнаць рана: калі маршрут поўнага тунэлю ўжо пакрывае 0.0.0.0/0, прэфікс не адсутнічае і паўторнае даданне нічога не зменіць. Двайное пакрыццё не выпраўляе адмову на баку сервера або адсутны адказ.

Завяршыце шлях на серверы

Тры рэчы павінны быць праўдай па-за тэлефонам. Шлюзу патрэбны маршрут да адрасата і дазвол перасылаць крыніцу тэлефона ў тым кірунку. Мэта павінна прымаць гэтую крыніцу і вяртаць адказы праз шлюз, інакш дызайн патрабуе наўмыснага пераўтварэння на выхадзе. Опцыя маршруту з кіраўніцтва OpenVPN апісвае дырэктыву боку кліента; перасылка і зваротная маршрутызацыя — асобныя налады на асобных машынах.

Калі адрасат знаходзіцца за іншым VPN-кліентам, а не непасрэдна за шлюзам, серверу патрэбен iroute для падсеткі гэтага партнёра. Гэтая дырэктыва належыць серверу і апісвае, які кліент валодае прэфіксам; тэлефон не можа падаць яе з уласнага профіля, і ніякая праўка на баку кліента яе не заменіць.

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

Адкат і прыёмка

Захавайце папярэдні профіль перад праўкай. Калі змена пагоршыць стан, аднавіце гэтую копію праз той самы шлях імпарту, перападключыцеся і пацвердзіце вяртанне ранейшых паводзінаў; гэта даказвае, што вы змянілі тое, што думалі. Адкат, які не вяртае ранейшы стан, азначае, што праграма трымае трэцюю копію, якую вы не знайшлі.

Прымайце змену, калі выконваюцца чатыры ўмовы, правераныя ў такім парадку пасля свежага перападключэння: адрасат адказвае на порт сэрвісу, прыватнае імя развязаецца, калі яго чакаюць, HTTPS па-ранейшаму пацвярджае патрэбнае імя хоста, і ўсё працуе пасля перазагрузкі або пераключэння з Wi-Fi на мабільную сетку. Апошняя праверка ловіць маршрут, які існуе толькі да таго часу, пакуль Android не адновіць тунэль.

• Пацвердзіце, што ўладальнік сеткі дазваляе адрасат, перш чым нешта правіць.
• Змесціце маршрут у профіль, які загружае кліент, потым імпартуйце нанова і перападключыцеся.
• Правярайце па порце сэрвісу, у межах per-app, для патрэбнага сямейства адрасоў.
• Выпраўляйце перасылку, зваротную маршрутызацыю і iroute на серверы, а не на тэлефоне.
• Трымайце копію для адкату і паўтарыце тэст пасля перазагрузкі.