Android правило једног VPN-а не блокира хостовани 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 имплементација следи исте називе конфигурације.