Правилото за един 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 реализация следва същите имена на настройки.