Android OpenVPN не дадае маршрут без адраса тунеля

Ваш профіль OpenVPN на Android не дадае маршрут, бо тэлефон не мае адраса на віртуальным інтэрфейсе, і маршруту няма куды паказваць. Маршруты кажуць толькі, куды павінны ісці пакеты. Адрас тунеля кажа, кім з’яўляецца тэлефон унутры тунеля, і кліент павінен даць яго, перш чым інтэрфейс зможа існаваць. Прайдзіце чатыры праверкі ніжэй па парадку і спыніцеся на першай няўдачы, бо змяненне маршрутаў да з’яўлення адраса хавае сапраўдную праблему.

Чытайце збой у тым парадку, у якім яго выконвае кліент

VpnService.Builder у Android раздзяляе два паняцці: addAddress() ставіць адрас на інтэрфейс, які будуе праграма, addRoute() дадае прэфікс прызначэння, а establish() адмаўляецца ствараць інтэрфейс, пакуль не дададзены хаця б адзін адрас. Кліент OpenVPN супастаўляе профіль і параметры, што перадае сервер, менавіта з гэтымі выклікамі, таму злучэнне без адраса не можа пабудаваць інтэрфейс.

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

Праверка 1: ці сервер дае адрас у адказе?

У маршрутызаванай службе OpenVPN адрас бярэцца з пула сервера або з прызначэння для кожнага кліента, а тапалогія вызначае яго форму. На серверы OpenVPN 2.4 або навейшым служба з тапалогіяй падсеткі выглядае так:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

У гэтай форме сервер перадае нешта накшталт ifconfig 10.8.0.6 255.255.255.0. Старэйшае разгортванне topology net30 перадае замест гэтага адрас партнёра, напрыклад ifconfig 10.8.0.6 10.8.0.5, таму профіль, перанесены паміж дзвюма мадэлямі, можа выглядаць правільным, але несці няправільную маску падсеткі.

Пашукайце ў журнале злучэння кліента набор перададзеных параметраў. Калі там няма ніводнага радка ifconfig, сервер ніколі не дасылаў адрас або кліент адхіліў параметр. На серверы з client-config-dir файл, названы па агульным імені ў сертыфікаце, павінен існаваць і змяшчаць прызначэнне:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Праверка 2: ці захоўвае кліент дадзены яму адрас?

Занадта шырокі фільтр — другая частая прычына. pull-filter існуе ў OpenVPN 2.4 і пазней, і калі некалькі фільтраў адпавядаюць аднаму параметру, перамагае апошні, таму заключны фільтр-улоўнік выдаляе адрас без памылкі:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Звужайце фільтр да параметра, які сапраўды трэба прыбраць, і пакіньце адрас у спакоі:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Парада адключыць усе pull звычайна ідзе ад таго, хто хоча пазбавіцца аднаго маршруту. route-nopull — вузнейшы перамыкач: ён захоўвае ifconfig і іншыя перададзеныя параметры, а адхіляе толькі перададзеныя маршруты і параметры DHCP. Ужывайце яго, калі гэта сапраўды тое, што трэба, і адказвайце на пытанне адраса асобна.

Праверка 3: ці адрас ваш, каб яго ўпісаць?

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

Прэфікс аддаленай LAN у маршруце — гэта пункт прызначэння, а не ідэнтычнасць тэлефона. Маршрут для 10.60.0.0/24 кажа: дасягні гэтую сетку праз тунель; ён не кажа, які менавіта адрас 10.60.0.x павінен мець тэлефон, і тэлефон не павінен мець ніводнага з іх. Статычныя прызначэнні месца на баку сервера, дзе яны не сутыкаюцца з дынамічным пулам.

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

Праверка 4: ці не займае месца тунеля нешта іншае?

Android дазваляе адну актыўную службу VPN адначасова. Іншая праграма VPN або запіс always-on, пакінуты ўключаным для профілю, які больш не працуе, могуць заняць гэтае месца раней, чым ваш кліент OpenVPN выкліча establish(). Тады інтэрфейс не з’явіцца зусім, хоць профіль слушны, таму адключыце іншы VPN, выключыце always-on і падключыцеся зноў, перш чым чапаць профіль.

Служба, якая патрабуе маставання Ethernet, — іншы тупік. Праграма Android без root можа стварыць IP-тунель, а не маставаны сегмент Ethernet, таму ніводзін упісаны адрас не прымусіць сервер dev tap працаваць; аператар павінен прапанаваць маршрутызаваную службу. Паведамляючы пра праблему, дадайце назву і версію кліента, набор перададзеных параметраў, тапалогію і дакладны крок, дзе павінен быў з’явіцца адрас.

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