Правіла аднаго VPN у Android не блакуе SSH-сервер на тэлефоне

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

Што насамрэч абмяжоўвае правіла аднаго VPN

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

Пра слухаючыя сокеты не сказана нічога. SSH-сервер не выклікае VpnService, не перахоплівае пакеты і не спаборнічае за гэты слот. Ён займае порт і прымае злучэнні — тое самае, што рабіў бы без усталяванага VPN. Такім чынам, міф блытае абмежаванне на пастаўшчыкоў тунеляў з абмежаваннем на сеткавыя злучэнні, а гэтыя рэчы не звязаныя.

Слухач — гэта пункт прызначэння, а не частка тунеля

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

Правілы прывязкі — звычайная канфігурацыя SSH: адрас і порт праслухоўвання, а таксама тое, каму дазволена аўтэнтыфікацыя. На Android гэтыя налады знаходзяцца ў канфігурацыі самой праграмы, і ўладальніку працэсу праграмы можа быць не дазволена выкарыстоўваць прывілеяваныя парты, таму звычка настольнай сістэмы займаць порт 22 ад імя root не пераносіцца без змен.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

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

Шлях адказу — месца, дзе звычайна ламаецца

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

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

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

Абыход VPN не рамантуе ўваходную службу

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

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

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

Дыягнастуйце па адным напрамку

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

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Праверку порта выконвайце з боку партнёра, а не з тэлефона, і чытайце падрабязны вывад кліента SSH, каб убачыць, ці збой адбываецца да ці пасля TCP-рукапаціскання. Сокет, які ніколі не падключаецца, і адхілены ўваход — гэта розныя этапы з рознымі ўладальнікамі.

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