Ang tuntunin ng isang VPN sa Android ay hindi humaharang sa naka-host na SSH server

Ang paniniwalang ito ay karaniwan na katanggap-tanggap na bilang katotohanan: isang VPN lang ang pinapayagan ng Android, kaya ang SSH server na tumatakbo sa telepono ay hindi maaaring gumana sa tunnel na iyon. Tama ang unang kalahati at hindi sumusunod ang konklusyon. Ang limitasyon ng platform ay tungkol sa kung ilang app ang maaaring humawak sa puwesto ng serbisyong VPN, hindi tungkol sa kung ilang socket ang maaaring umiral o sino ang pinapayagang kumonekta sa telepono. Ang SSH daemon na may nakikinig na socket ay ordinaryong app na may ordinaryong port, at ang tunnel ay isa sa mga landas na maaaring tahakin ng trapiko nito.

Ano ba talaga ang nililimitahan ng tuntunin ng isang VPN

VpnService ay isang mapagkukunang may isang puwesto. Kapag nagtatag ang isang app ng tunnel, ito ang nagiging VPN ng device, at ang pangalawang app na magtatangkang magtatag ng isa ay tinatanggihan hanggang mawala ang una. Iyon ay tuntunin tungkol sa pagmamay-ari ng tunnel, at ipinapaliwanag nito kung bakit hindi maaaring tumakbo nang sabay ang dalawang VPN client.

Wala itong sinasabi tungkol sa mga nakikinig na socket. Hindi tumatawag ang SSH server sa VpnService, hindi nanghihimasok sa mga packet at hindi nakikipag-agawan sa puwestong iyon. Nagbibigkis ito ng port at tumatanggap ng koneksyon, kapareho ng gagawin nito nang walang naka-install na VPN. Kaya pinaghahalo ng alamat ang limitasyon sa mga tagapagbigay ng tunnel at ang limitasyon sa mga koneksyon sa network, at walang kaugnayan ang dalawa.

Ang listener ay destinasyon, hindi bahagi ng tunnel

Kapag umiiral ang tunnel, may address ang telepono dito at may ruta ang kasalungat na device patungo sa address na iyon. Kung may sasagot ay ang listener ang nagpapasya. Ang daemon na nakatali sa loopback ay maaabot lamang mula sa telepono mismo; ang daemon na nakatali sa lumang address ng tunnel ay maaaring mapanatili ang pagkakatali pagkatapos ng muling pagkonekta kahit nagbago na ang address kung saan ito nakatali.

Ang mga tuntunin ng pagkakatali ay ordinaryong SSH configuration: ang address at port ng pakikinig, at kung sino ang maaaring magpatunay. Sa Android, ang mga setting na iyon ay nasa sariling configuration ng app, at ang may-ari ng proseso ng app ay maaaring hindi pinapayagang gumamit ng privileged ports, kaya ang ugali sa desktop na magbigkis ng port 22 bilang root ay hindi lumilipat nang walang pagbabago.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Pagkatapos ay may pahintulot mismo sa landas. Ang consumer VPN na malugod na nagdadala ng papalabas na web traffic ay hindi kailangang payagan ang mga papasok na koneksyon sa mga kliyente nito; marami ang hindi, dahil ilalantad nito ang isang customer sa iba. Kung hindi maabot ng kasalungat ang address ng tunnel ng telepono mula saanman, ang problema ay nasa patakaran ng serbisyo at hindi sa telepono.

Ang landas ng tugon ang karaniwang nasisira

Ipagpalagay na naabot ng kasalungat ang address ng tunnel ng telepono at dumating ang SYN. Ngayon ang tugon ay kailangang lumabas sa parehong landas, at iyon ay desisyon sa pagruruta sa loob ng telepono. Kung lumalabas ang tugon sa Wi-Fi dahil iyon ang default na network, makikita ng kasalungat ang koneksyong hindi natatapos, na mukhang firewall.

Ginagawang mas kumplikado ito ng Android kaysa desktop dahil pinipili ang default na network ayon sa proseso at maaaring baguhin ng patakaran ng VPN app. Ang VPN client ay makakapagruta lamang ng listahan ng pinapayagang app, kaya ang server app na nasa labas ng listahang iyon ay patuloy na gumagamit ng pisikal na network para sa mga tugon nito habang hinihintay ng kasalungat ang mga ito sa tunnel.

Maaari ring itali ng app ang sarili nitong mga socket sa isang partikular na network, na pumapalit sa default. Kapag nagbasa ka ng ulat na naaabot ang isang serbisyo mula sa isang address at hindi mula sa iba, karaniwang ito ang mekanismong nasa likod.

Hindi inaayos ng paglampas sa VPN ang papasok na serbisyo

Ang popular na solusyon, ibukod ang SSH app sa VPN upang tumigil ang pag-redirect ng trapiko nito, ay pagwawasto para sa kabaligtarang problema. Nakakatulong ito kapag ang transport ng papalabas na SSH client ay paulit-ulit na nasisira dahil sa tunnel. Para sa naka-host na server, maaari nitong ilabas ang mga tugon sa tunnel na ginagamit ng kasalungat, na ginagawang ganap ang bahagyang pagpalya.

Ganoon din sa pagbubukas ng pampublikong port sa router. Kung ang pangangailangan ay maabot ng isang awtorisadong device ang telepono sa pamamagitan ng VPN, ang paglalantad ng SSH sa internet ay ibang modelo ng banta at hindi pag-aayos.

Magpasya muna sa address ng serbisyo: ang LAN address ng telepono, ang address nito sa tunnel, o isang sadyang ipinasa na endpoint. Bawat isa ay may sariling kontrata sa maaabot at paglalantad, at ang paghahalo sa kanila ang paraan para maging permanenteng butas ang maliit na problema sa access.

Tukuyin ang isang direksyon sa isang pagkakataon

Isulat ang apat na katotohanan bago baguhin ang configuration: ang address na kinokonektahan ng kasalungat, ang kalagayan ng listener sa telepono, ang konteksto ng app at user na may-ari nito, at ang landas na naobserbahan sa bawat direksyon. Ang ulat na nagsasabing dinidiskonekta ng VPN ang SSH ay wala ni isa sa mga iyon at hindi matukoy ang problema sa transport ng client mula sa hindi maabot na server.

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

Patakbuhin ang pagsusuri ng port mula sa kasalungat, hindi sa telepono, at basahin ang detalyadong output ng SSH client upang makita kung nabigo ito bago o pagkatapos ng TCP handshake. Ang socket na hindi kailanman kumokonekta at ang tinanggihang pag-login ay magkaibang yugto na may magkaibang may pananagutan.

Panatilihing buo ang pagpapatunay ng host key at mga paghihigpit sa account habang nagde-debug. Ang paglimita sa listener at sa mga pinapayagang user ang gumagawa ng maaabot na server na katanggap-tanggap; ang pagluwag sa mga ito upang gumana ang koneksyon ay nagpapalit ng isang problema sa mas malala. Saklaw ng sanggunian ng OpenSSH server ang mga kontrol sa pakikinig at pag-access kung sinusunod ng iyong Android implementation ang parehong mga pangalan ng configuration.