Rregulli i një VPN-je në Android nuk bllokon një server SSH të strehuar

Ky besim është mjaft i përhapur sa trajtohet si fakt: Android lejon vetëm një VPN, prandaj një server SSH që punon në telefon nuk mund të funksionojë përmes atij tuneli. Gjysma e parë është e vërtetë dhe përfundimi nuk rrjedh prej saj. Kufizimi i platformës ka të bëjë me atë se sa aplikacione mund të zënë vendin e shërbimit VPN, jo me atë se sa socket-e mund të ekzistojnë ose kush lejohet të lidhet me telefonin. Një daemon SSH me një socket dëgjues është një aplikacion i zakonshëm me një port të zakonshëm, dhe tuneli është një nga rrugët që mund të marrë trafiku i tij.

Çfarë kufizon në të vërtetë rregulli i një VPN-je

VpnService është një burim me një vend. Kur një aplikacion vendos një tunel, ai bëhet VPN-ja e pajisjes, dhe aplikacioni i dytë që përpiqet të vendosë një refuzohet derisa i pari të zhduket. Ky është një rregull për pronësinë e tunelit dhe shpjegon pse dy klientë VPN nuk mund të punojnë njëkohësisht.

Nuk thotë asgjë për socket-et dëgjuese. Serveri SSH nuk e thërret VpnService, nuk i përgjon paketat dhe nuk konkurron për atë vend. Lidh një port dhe pranon lidhje, e njëjta gjë që do të bënte pa asnjë VPN të instaluar. Pra miti ngatërron një kufi për ofruesit e tuneleve me një kufi për lidhjet e rrjetit, dhe të dyja nuk kanë asnjë lidhje.

Dëgjuesi është një destinacion, jo pjesë e tunelit

Pasi tuneli ekziston, telefoni ka një adresë mbi të dhe pajisja partnere ka një rrugë drejt asaj adrese. Nëse diçka përgjigjet vendos dëgjuesi. Një daemon i lidhur me loopback është i arritshëm vetëm nga vetë telefoni; një daemon i lidhur me adresën e vjetër të tunelit mund ta mbajë lidhjen pas një rilidhjeje edhe pse adresa me të cilën u lidh ka ndryshuar.

Rregullat e lidhjes janë konfigurim i zakonshëm SSH: adresa dhe porti i dëgjimit, dhe kush mund të vërtetojë identitetin. Në Android ato cilësime jetojnë në konfigurimin e vetë aplikacionit, dhe pronarit të procesit të aplikacionit mund të mos i lejohet përdorimi i porteve të privilegjuara, prandaj zakoni i desktopit për të lidhur portin 22 si root nuk transferohet i pandryshuar.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Pastaj është leja në vetë rrugën. Një VPN konsumatori që transporton me kënaqësi trafikun web dalës nuk ka pse të lejojë fare lidhje hyrëse drejt klientëve të tij; shumë nuk e bëjnë, sepse do të ekspozonte një klient ndaj tjetrit. Nëse partneri nuk mund ta arrijë adresën e tunelit të telefonit nga askund, problemi qëndron në politikën e shërbimit dhe jo në telefon.

Rruga e përgjigjes është vendi ku zakonisht thyhet

Supozojmë se partneri arrin adresën e tunelit të telefonit dhe SYN mbërrin. Tani përgjigja duhet të dalë nga e njëjta rrugë, dhe ky është një vendim rrugëtimi brenda telefonit. Nëse përgjigja del përmes Wi-Fi sepse ai është rrjeti i parazgjedhur, partneri sheh një lidhje që nuk përfundon kurrë, e cila duket saktësisht si një firewall.

Android e bën këtë më të ndërlikuar se një desktop sepse rrjeti i parazgjedhur zgjidhet për çdo proces dhe mund të ndryshohet nga politika e aplikacionit VPN. Një klient VPN mund të rrugëtojë vetëm një listë aplikacionesh të lejuara, prandaj një aplikacion server jashtë asaj liste vazhdon të përdorë rrjetin fizik për përgjigjet e tij ndërsa partneri i pret përmes tunelit.

Një aplikacion mund të lidhë gjithashtu socket-et e veta me një rrjet të caktuar, gjë që anashkalon të parazgjedhurin. Kur lexoni një raport se një shërbim është i arritshëm nga një adresë dhe jo nga një tjetër, zakonisht ky është mekanizmi pas tij.

Anashkalimi i VPN nuk riparon një shërbim hyrës

Zgjidhja popullore, përjashtimi i aplikacionit SSH nga VPN që trafiku i tij të mos ridrejtohet më, është një rregullim për problemin e kundërt. Ndihmon kur transporti i një klienti SSH dalës thyhet vazhdimisht për shkak të tunelit. Për një server të strehuar mund t'i nxjerrë përgjigjet jashtë tunelit që po përdor partneri, gjë që e kthen një dështim të pjesshëm në një të plotë.

E njëjta gjë vlen për hapjen e një porti publik në router. Nëse kërkesa është që një pajisje e autorizuar të arrijë telefonin përmes VPN, ekspozimi i SSH në internet është një model tjetër kërcënimi dhe jo një riparim.

Vendosni së pari adresën e shërbimit: adresën LAN të telefonit, adresën e tunelit ose një pikë fundore të përcjellë qëllimisht. Secila ka kontratën e vet të arritshmërisë dhe ekspozimit, dhe përzierja e tyre është mënyra se si një problem i vogël aksesi bëhet një vrimë e përhershme.

Diagnostikon një drejtim në një kohë

Shkruani katër fakte përpara se të ndryshoni konfigurimin: adresën me të cilën lidhet partneri, gjendjen e dëgjuesit në telefon, kontekstin e aplikacionit dhe përdoruesit që e zotëron, dhe rrugën e vëzhguar në çdo drejtim. Një raport që thotë se VPN shkëput SSH nuk përmban asnjë prej tyre dhe nuk mund të dallojë një problem transporti të klientit nga një server i paarritshëm.

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

Ekzekutoni kontrollin e portit nga partneri, jo nga telefoni, dhe lexoni daljen e detajuar të klientit SSH për të parë nëse dështon përpara ose pas shtrëngimit të duarve TCP. Një socket që nuk lidhet kurrë dhe një hyrje e refuzuar janë faza të ndryshme me përgjegjës të ndryshëm.

Mbajini të paprekura verifikimin e çelësit të hostit dhe kufizimet e llogarisë gjatë korrigjimit. Pikërisht kufizimi i dëgjuesit dhe i përdoruesve të lejuar e bën të pranueshëm një server të arritshëm; lirimi i tyre që një lidhje të funksionojë ndërron një problem me një më të keq. Referenca e serverit OpenSSH mbulon kontrollet e dëgjimit dhe aksesit nëse zbatimi juaj i Android ndjek të njëjtat emra konfigurimi.