Автоматическое включение vpn андроид

Автоматическое подключение VPN на Android (и немного iOS)

И так. В метро есть хороший Wi-Fi, бывают косяки, но в целом удовлетворительно. Никогда и нигде не подключаюсь к общественным Wi-Fi сетям без острой необходимости и без отсутсвия альтернатив (режим модема), ибо так и вижу, как прыгнул в контейнер с мусором. Поэтому обратимся за помощью к Durex, то есть к VPN. И автоматизируем весь этот процесс «вхождения», ибо мне влом специально заходить и подключатсья к VPN, а потом его отключать.

Сервисов куча на любой цвет и вкус, на первых ссылках гугла найдете их все. Но меня все они не устроили по одной простой причине. Цена. Минимум 3$ за месяц, чаще 5$, реже 7$ и 9$. Брать годовые тарифы тоже не вариант, с текущим курсом все равно выходит жирно, чтобы полситать твиттер в метро около получаса-часа в день.

Альтернатива 1. Поднять дома VPN. Но у меня домашний ПК на OS X, а как оказалось, OS X Server не хочется «цеплять» Android. Проблема массовая, решения нет.

Альтернатива 2. Поднять Windows в Parallels/VMware на OS X и на винде поднять VPN. Но это уже слишком костыльно выходило и держать вируталку ради VPN и отъедать ресурсы компа не хотелось, решил оставить на последний вариант.

Альтернатива 3. Есть роутер Asus и для него доступна прошивка от Padavan. Прошил, нашел вкладку VPN сервера, нашел инструкцию, как поднять на роутере VPN сервер OpenVPN. Оказался криворуким и забил на это.

Альтернатива 4. Благодаря альтернативе 3 вспомнил о существование OpenVPN. В общем, пока туда-сюда «ползал» подвел итог, что все равно нужен сервер где-то поднимать, а это либо у себя делать (привет кривые руки), либо DigitalOcean и тому подобные штуки за $ каждый месяц.

Альтернатива 5. Однако на OpenVPN нашелся сервис www.privatetunnel.com от создателей OpenVPN.

1. Доступен на всех платформах.
2. Сервера в Америке и в Европе.
3. И самое главное и самое лучшее: 12$ за 100 ГБ трафика… Без временных сроков! Только когда израсходуешь пакет, тогда снова и заплати. Шикарный вариант. Для метро полистать твиттер и перекинуться сообщениями 100 гигабайт хватит на полгода минимум, если не на пару лет.

В итоге www.privatetunnel.com самый лучший вариант, если вам нужен VPN, но платить ежемесячно от 500р и более слишком.

Автоматическое подключение VPN

3. Открываете файл в любом редакторе, я открыл Atom’ом.

Источник

Постоянная VPN на Android

Для доступа извне к ресурсам в локальной сети обычно используют обратный прокси (reverse proxy) или VPN. В материале описываются странности и методы их обхода при настройке Always-on (постоянного) VPN на Android.

Евгений Боздаганян

Read more posts by this author.

Евгений Боздаганян

Ресурсы локальных сетей и доступ к ним

Время от времени я возвращаюсь к теме VPN — виртуальной частной сети. Делаю я это по нескольким причинам. Главные, конечно, приватность и безопасность. или, может лучше, в обратном порядке: безопасность и приватность. Есть в этом, также, определённый момент отсутствия знаний. Сейчас попробую пояснить.

Я не устаю напоминать, что использую некоторое количество self-hosted сервисов. Достаточно часто я «выставляю» их интерфейс наружу — делаю я это потому, что такой подход облегчает доступ к реализованному в этих сервисах функционалу. При этом, я стараюсь как-то обезопасить и себя, и сервисы, поэтому перед всеми этими WebUI использую «обратный» прокси (reverse proxy).

Обычно, конфигурирование этого прокси [1] для обеспечения доступа к сервисам, не представляет проблем. Но, время от времени, я сталкиваюсь со сложной (возможно, только для меня) задачей. И если, за какое-то резонное время, у меня не получается её решить (самостоятельно ли, с помощью Гугла ли), я вспоминаю, что альтернативой является VPN .

Об одну из таких задач я споткнулся совсем недавно. У меня, достаточно давно, реализован доступ к административному интерфейсу моего домашнего роутера. При этом, на даче у меня тоже есть роутер, да не один. Недавно я провёл работы по объединению домашней и дачной сетей — при помощи SoftEther VPN. К сожалению, все свои задумки мне реализовать не удалось (надеюсь, что пока), но уже сейчас я могу из домашней сети, без каких бы то ни было танцев с бубнами, открыть web интерфейс дачных MikroTik-ов. Что за танцы с бубнами? Ну те, которые приходится исполнять из-за отсутствия «белого», пусть даже «динамического», IP адреса на даче.

Доступ извне при помощи обратного прокси

Как говорится, не было забот. После того, как дотянуться до интерфейса MikroTik -ов из домашней сети стало так же просто, как и до интерфейса Keenetic-а, у меня зачесались руки обеспечить этот доступ через свой обратный прокси. Ну, чтобы, находясь за пределами своих локальных сетей, можно было бы без подключения к VPN , вбив адрес в браузере на планшете, посмотреть, как чувствуют себя дачные роутеры. И тут, достаточно неожиданно, выяснилось, что обычный мой подход не срабатывает.

Несколько слов о том, что это за подход такой [2] . Раньше я использовал для доступа к домашнему роутеру домен третьего уровня, и, так как на него у меня выпущен сертификат Let’s Encrypt (мой обратный прокси ещё и терминирует SSL трафик), я решил оставить домен, как есть. Ну а раз теперь количество роутеров увеличилось, то я решил, что устройство, к которому идёт обращение, буду определять через путь, ну, например, my.domain.com/keenetic для домашнего Keenetic -а, а my.domain.com/mikrotik-1 для MikroTik -а, выполняющего роль CAPsMAN-а.

Я и раньше проделывал подобные трюки. Для решения приходилось модифицировать путь, чтобы на backend -сервер приходил правильный URL . Но, в этом случае, данный подход не сработал. Я смог отобразить страницу ввода пароля MikroTik , после чего процесс застопорился. Я подозреваю, что роутер как-то хитро выстраивает работу с адресами, но уловить, как именно, пока не могу. А без точного понимания того, как осуществляются переходы, не могу правильно модифицировать путь.

VPN — альтернатива обратному прокси

Побившись некоторое время головой об стену, я решил, что выставлять наружу web интерфейс роутера — не такая уж и правильная затея [3] . А кроме выставления чего-либо наружу, мне известен лишь один другой подход — самому спрятаться внутрь — то бишь, задействовать VPN .

Когда я нахожусь в зонах своих локальных сетей, я использую именно VPN , когда обращаюсь к ресурсам удалённой локалки. Просто это происходит прозрачно — благодаря настройкам на роутерах (и не только). Но когда я вне этих зон, то для доступа к ресурсам локальных сетей приходится явно подключаться к определённой VPN сети. Когда это делаешь раз-два в месяц, можно и потерпеть, но если тебе это нужно несколько раз в день, то необходимость постоянно входить/выходить в настройки того же Android , слегка утомляет.

Можно, конечно, подключиться к VPN один раз, и надеяться, что не произойдёт разъединения, но, обычно, такой фокус не прокатывает — соединение обязательно будет разорвано, к тому же, об этом, как правило, узнаёшь только тогда, когда пытаешься обратиться к удалённому локальному ресурсу.

И тут я вспомнил о такой замечательной настройке, как Постоянная VPN ( Always-On VPN ). Документация [4] обещает, что при задействовании этой опции, соединение с VPN будет устанавливаться автоматически, например, при перезагрузке устройства. К тому же, в случае потери соединения, система вас обязательно оповестит.

Always-On VPN. Проблема.

Как водится, я решил опробовать этот новый для меня функционал. Но тут меня тоже ожидали испытания. Казалось бы, что может пойти не так при попытке, по сути, включить «галку»? Ответ на этот вопрос прост до безобразия — после этого элементарного действия подключиться к VPN становится невозможно! Соответствующая кнопка становится недоступна.

Меня, конечно, повеселила сама логика «отложенной» проверки. Ведь что, по сути, происходит: какие-то условия, необходимые для того, чтобы использование постоянной VPN стало возможным, не выполняются. В такой ситуации было бы логичным сделать недоступным соответствующий переключатель. Но, видимо, чтобы не расстраивать пользователя, что у него что-то не так, ему об этом просто не говорят — вдруг он не захочет использовать этот функционал вообще? И выходит, что проблемы, как бы, не существует — ровно до того момента, пока не попробуешь включить нужный тебе режим. Надо бы взять на вооружение такой подход, пользователям, наверное, понравится 😏.

Ладно, шутки шутками, но теперь, когда я не смог включить постоянное использование VPN , этот режим стал мне просто жизненно необходим 😄. В общем, я вновь обратился к документации. Надо сказать, что никаких предварительных требований, выполнение которых необходимо для того, чтобы VPN стала постоянной, я не увидел. Возможно, есть более подробная и точная документация, и я её просто не нашёл.

Потерпев неудачу в поиске ответа в документации, я переключился на всевозможные форумы. И тут сразу стало ясно, что я не один такой. После чтения пары-тройки обсуждений у меня появилось понимание того, что, примерно, происходит в моём случае.

Always-On VPN. Причины неудач.

Начну издалека. Мой провайдер выдаёт мне условно постоянный белый IP . Условность заключается в том, что IP не меняется, пока во взаимодействии с провайдером всё стабильно: тарифный план постоянен и всегда вовремя оплачен. Когда у меня в качестве домашнего роутера выступал ASUS RT-N56U, IP изменялся всего пару раз — когда я забывал вовремя оплатить интернет.

Однако, после смены роутера на Keneetic Viva, IP адрес стал меняться каждый месяц — аккурат в ночь на первое число нового месяца. И это никак не связано с оплатой. Изменились ли условия у провайдера и это просто совпало со сменой роутера, или это особенность нового устройства — я, если честно, не знаю и выяснять не хочу. И раньше, когда адреса не менялись каждый месяц, и сейчас, когда это происходит, я использую вместо самого адреса собственный домен, который к этому адресу привязан. Просто сейчас, в начале каждого месяца, я меняю привязку домена у своего регистратора — задаю новый адрес, благо, регистратор предоставляет соответствующее API .

Из обсуждений на форумах следовало, что указывать домен в настройках VPN , если есть желание использовать виртуальную сеть на постоянной основе, нельзя, надо указывать непосредственно адрес. На одном из форумов Google была ветка, сообщения в которой объясняли причину такого ограничения/требования: для того, чтобы привести имя домена VPN сервиса к адресу, придётся пропустить через межсетевой экран ( firewall ) запросы к DNS серверу, и создатели абсолютно безопасной системы Android (это сарказм, если что 😏), боялись, что это может существенно подорвать эту самую безопасность. Как? Типа, злоумышленники перенаправят запросы на свой DNS сервер, подсунут вместо истинного сервера VPN свой дубликат, после чего получат доступ ко всей конфиденциальной информации, которую наивный пользователь пустит через установленное VPN соединение.

Что ж, в теории такая атака возможна. Какие усилия надо приложить, чтобы её осуществить, я не буду оценивать — не являюсь экспертом в области безопасности. Ну, раз боятся, значит, есть основания — они-то точно знают систему лучше, причём, изнутри, и, исходя из этого знания, могут адекватнее оценивать риски (а это была подколка 😏).

Always-On VPN. Настройка.

Ладно, изменил я имя домена на IP адрес, хотя, если честно, уверенности, что теперь я стану использовать эту возможность (постоянную VPN ), у меня поубавилось. И что вы думаете, произошло? Да ровным счётом — ничего. Кнопка как была недоступной, так и осталась таковой.

Поразмыслив немного, я решил в дополнительных настройках VPN соединения указать адрес DNS сервера. Ведь если следовать логике, то DNS сервер тоже может быть задан в виде имени домена. Указание же адреса DNS сервера в настройках соединения, сделает использование именно его обязательным, приводить имя домена к адресу не придётся, безопасность останется на высоте, ну и вот это вот всё.

И действительно, после этой правки подключить постоянное VPN соединение стало возможным.

Послесловие

Все хорошо, что хорошо заканчивается. Вот только, как уже писал выше, я теперь и не знаю, нужно ли мне такое постоянное соединение. Ведь раз в месяц мне точно придётся его перенастраивать. Ну или придётся вплотную заняться проблемой изменения «белого» IP адреса — а я не уверен, что смогу её решить. Но, в любом случае, я рад, что мне удалось настроить постоянное VPN подключение: «мужик сказал — мужик сделал» 😂.

Ну и, под конец, парочка интересных особенностей постоянного VPN соединения, с которыми мне довелось столкнуться [5] . Во-первых, после включения режима весь трафик идёт через VPN , любая попытка «проскочить» в обход, видимо, обречена на провал. Я попробовал задать Маршруты пересылки в Дополнительных настройках VPN соединения, в результате, весь остальной трафик просто был «обрезан». Во-вторых, отключение постоянного VPN соединения тоже процедура не совсем очевидная: при попытке отсоединиться вручную коннект автоматически восстанавливается — VPN же постоянный 😃. Мне пришлось отключить сначала WiFi и только после этого получилось добраться до «галки» Постоянная VPN .

Ну что ж, на этом, пока, всё.

Я использую HAProxy ↩︎

Чисто, чтобы выговориться. К тому же, когда объясняешь свои манипуляции, нет-нет да и найдёшь причину неудач ↩︎

Можно сказать, чуть изменив крылатое выражение из мультфильма «Маугли»: через трещину в голове, возможно, вошло немного ума. ↩︎

Пусть заголовок Android Enterprise не вводит в заблуждение — сейчас речь именно о возможностях самого устройства. ↩︎

Есть ненулевая вероятность, что данный фактаж зависит от производителя устройства. ↩︎

Subscribe to Записки на полях

Get the latest posts delivered right to your inbox

Адресация self-hosted сервисов при помощи поддоменов

Применение поддоменов в адресах self-hosted сервисов, использование DNS записей A-record и CNAME-record при описании поддоменов у регистратора

История о том, как меня «взломали».

Поучительная история о том, как недостаточное внимание, уделяемое вопросам безопасности, может привести к нежелательным последствиям — взлому домашней IP камеры.

Subscribe to Записки на полях

Stay up to date! Get all the latest & greatest posts delivered straight to your inbox

Источник