Az Android egy-VPN szabálya nem blokkol egy hosztolt SSH-kiszolgálót

A hiedelem elég elterjedt ahhoz, hogy tényként kezeljék: az Android csak egy VPN-t engedélyez, ezért a telefonon futó SSH-kiszolgáló nem működhet azon az alagúton keresztül. Az első fele igaz, és a következtetés nem következik belőle. A platform korlátja arról szól, hány alkalmazás foglalhatja el a VPN-szolgáltatás helyét, nem arról, hány socket létezhet, vagy ki csatlakozhat a telefonhoz. A figyelő socketet tartó SSH-démon közönséges alkalmazás közönséges porttal, az alagút pedig egyike azoknak az utaknak, amelyeken a forgalma haladhat.

Mit korlátoz valójában az egy-VPN szabály

VpnService egyhelyes erőforrás. Amikor egy alkalmazás alagutat létesít, az lesz az eszköz VPN-je, és a második alkalmazást, amely szintén alagutat próbál létesíteni, elutasítják, amíg az első meg nem szűnik. Ez az alagút tulajdonáról szóló szabály, és megmagyarázza, miért nem futhat két VPN-kliens egyszerre.

A figyelő socketekről semmit nem mond. Az SSH-kiszolgáló nem hívja a VpnService-et, nem fog el csomagokat, és nem verseng azért a helyért. Portot köt és kapcsolatokat fogad, ugyanazt teszi, amit VPN telepítése nélkül tenne. A mítosz tehát az alagútszolgáltatókra vonatkozó korlátot keveri a hálózati kapcsolatok korlátjával, és a kettőnek semmi köze egymáshoz.

A figyelő célpont, nem az alagút része

Amikor az alagút létezik, a telefonnak van rajta címe, a partnergépnek pedig útvonala ehhez a címhez. Hogy válaszol-e valami, azt a figyelő dönti el. A loopbackhez kötött démon csak magáról a telefonról érhető el; a régi alagútcímhez kötött démon megtarthatja a kötését újracsatlakozás után is, miközben a cím, amelyhez kötődött, megváltozott.

A kötési szabályok közönséges SSH-konfigurációk: a figyelési cím és port, valamint hogy ki hitelesíthet. Androidon ezek a beállítások az alkalmazás saját konfigurációjában élnek, és előfordulhat, hogy az alkalmazás folyamatának tulajdonosa nem használhat privilegizált portokat, így az asztali szokás, hogy a 22-es portot rootként köti, nem vihető át változatlanul.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Aztán ott van az engedély magán az úton. Egy fogyasztói VPN, amely szívesen szállít kimenő webforgalmat, egyáltalán nem köteles engedélyezni a bejövő kapcsolatokat az ügyfelei felé; sok nem is teszi, mert ezzel az egyik ügyfelet a másiknak tenné ki. Ha a partner sehonnan nem éri el a telefon alagútcímét, a probléma a szolgáltatás szabályzatában van, nem a telefonban.

A válaszút az, ahol általában eltörik

Tegyük fel, hogy a partner eléri a telefon alagútcímét, és megérkezik a SYN. A válasznak most ugyanazon az úton kell kifelé mennie, és ez a telefonon belüli útvonalválasztási döntés. Ha a válasz Wi-Fi-n megy ki, mert az az alapértelmezett hálózat, a partner egy soha be nem fejeződő kapcsolatot lát, ami pontosan úgy néz ki, mint egy tűzfal.

Az Android bonyolultabbá teszi ezt, mint egy asztali gép, mert az alapértelmezett hálózatot folyamatonként választják ki, és a VPN-alkalmazás szabályzata megváltoztathatja. Egy VPN-kliens csak az engedélyezett alkalmazások listáját tudja átirányítani, így az ezen a listán kívüli kiszolgálóalkalmazás továbbra is a fizikai hálózatot használja a válaszaihoz, miközben a partner azokat az alagúton keresztül várja.

Egy alkalmazás a saját socketjeit is kötheti egy adott hálózathoz, ami felülírja az alapértelmezettet. Amikor olyan jelentést olvas, hogy egy szolgáltatás az egyik címről elérhető, a másikról nem, általában ez a mechanizmus áll mögötte.

A VPN megkerülése nem javítja meg a bejövő szolgáltatást

A népszerű kerülőút, az SSH-alkalmazás kizárása a VPN-ből, hogy a forgalma ne legyen átirányítva, az ellenkező probléma javítása. Akkor segít, amikor egy kimenő SSH-kliens átvitele az alagút miatt folyton megtörik. Hosztolt kiszolgálónál kivigye a válaszokat abból az alagútból, amelyet a partner használ, ami a részleges hibát teljes hibává változtatja.

Ugyanez vonatkozik a nyilvános port megnyitására a routeren. Ha az a követelmény, hogy egy engedélyezett eszköz a VPN-en keresztül érje el a telefont, az SSH internetre való kitettsége más fenyegetésmodell, és nem javítás.

Először döntse el a szolgáltatás címét: a telefon LAN-címét, alagútcímét vagy egy szándékosan továbbított végpontot. Mindegyiknek megvan a maga elérhetőségi és kitettségi szerződése, és ezek összekeverése az, ahogy egy kis hozzáférési probléma állandó lyukká válik.

Egyszerre egy irányt diagnosztizáljon

Négy tényt írjon le a konfiguráció módosítása előtt: a címet, amelyre a partner csatlakozik, a figyelő állapotát a telefonon, az őt birtokló alkalmazás- és felhasználói kontextust, valamint az egyes irányokban megfigyelt utat. Az a jelentés, amely szerint a VPN megszakítja az SSH-t, egyiket sem tartalmazza, és nem tudja megkülönböztetni a kliens átviteli problémáját az elérhetetlen kiszolgálótól.

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

A portellenőrzést a partnerről futtassa, ne a telefonról, és olvassa el az SSH-kliens részletes kimenetét, hogy lássa, a TCP-kézfogás előtt vagy után hibázik-e. Az a socket, amely soha nem kapcsolódik, és az elutasított bejelentkezés különböző szakaszok különböző felelősökkel.

Hibakeresés közben tartsa érintetlenül a hostkulcs-ellenőrzést és a fiókkorlátozásokat. A figyelő és az engedélyezett felhasználók korlátozása az, ami elfogadhatóvá tesz egy elérhető kiszolgálót; ezek lazítása, hogy egy kapcsolat működjön, egy problémát egy rosszabbra cserél. Az OpenSSH-kiszolgáló referenciája lefedi a figyelési és hozzáférési vezérlőket, ha az Android-implementációja ugyanazokat a konfigurációs neveket követi.