Android యొక్క ఒకే VPN నియమం హోస్ట్ చేసిన SSH సర్వర్‌ను నిరోధించదు

ఈ నమ్మకం వాస్తవంగా పరిగణించేంత సాధారణం: Android ఒకే VPN ను అనుమతిస్తుంది, కాబట్టి ఫోన్‌లో నడిచే SSH సర్వర్ ఆ టన్నెల్ ద్వారా పని చేయలేదు. మొదటి సగం నిజం, ముగింపు దాని నుండి రాదు. ప్లాట్‌ఫారమ్ పరిమితి ఎన్ని యాప్‌లు VPN సేవ స్థానాన్ని పట్టుకోగలవు అనే దానికి సంబంధించినది, ఎన్ని సాకెట్లు ఉండగలవు లేదా ఎవరు ఫోన్‌కు కనెక్ట్ కాగలరు అనే దానికి కాదు. వినే సాకెట్ ఉన్న SSH డీమన్ సాధారణ పోర్ట్ ఉన్న సాధారణ యాప్, మరియు టన్నెల్ దాని ట్రాఫిక్ వెళ్ళగల మార్గాలలో ఒకటి.

ఒకే VPN నియమం నిజానికి ఏమి పరిమితం చేస్తుంది

VpnService ఒకే స్లాట్ వనరు. యాప్ టన్నెల్ ఏర్పాటు చేసినప్పుడు అది పరికరం యొక్క VPN అవుతుంది, మరియు టన్నెల్ ఏర్పాటు చేయడానికి ప్రయత్నించే రెండవ యాప్ మొదటిది పోయే వరకు తిరస్కరించబడుతుంది. ఇది టన్నెల్ యాజమాన్యం గురించిన నియమం, మరియు రెండు VPN క్లయింట్లు ఒకేసారి ఎందుకు నడవలేవో వివరిస్తుంది.

ఇది వినే సాకెట్ల గురించి ఏమీ చెప్పదు. SSH సర్వర్ VpnService ను పిలవదు, ప్యాకెట్లను అడ్డగించదు, ఆ స్లాట్ కోసం పోటీ పడదు. ఇది పోర్ట్ బైండ్ చేసి కనెక్షన్లను ఆమోదిస్తుంది, VPN ఏమీ ఇన్‌స్టాల్ చేయనప్పుడు కూడా అదే పని చేస్తుంది. కాబట్టి ఈ పురాణం టన్నెల్ ప్రొవైడర్ల పరిమితిని నెట్‌వర్క్ కనెక్షన్ల పరిమితితో కలిపేస్తుంది, రెండింటికీ మధ్య ఎలాంటి సంబంధం లేదు.

లిసనర్ ఒక గమ్యం, టన్నెల్ భాగం కాదు

టన్నెల్ ఉన్నప్పుడు, ఫోన్‌కు దానిపై ఒక చిరునామా ఉంటుంది, సహచర పరికరానికి ఆ చిరునామాకు మార్గం ఉంటుంది. ఏదైనా ప్రతిస్పందిస్తుందా అనేది లిసనర్ నిర్ణయిస్తుంది. loopback కు బద్ధమైన డీమన్ ఫోన్ నుండి మాత్రమే చేరుకోగలం; పాత టన్నెల్ చిరునామాకు బద్ధమైన డీమన్ మళ్లీ కనెక్ట్ అయిన తర్వాత కూడా తన బంధాన్ని కొనసాగించవచ్చు, కానీ అది బద్ధమైన చిరునామా మారిపోయింది.

బైండింగ్ నియమాలు సాధారణ SSH కాన్ఫిగరేషన్: వినే చిరునామా మరియు పోర్ట్, మరియు ఎవరు ప్రామాణీకరించుకోగలరు. Android లో ఆ సెట్టింగ్‌లు యాప్ యొక్క స్వంత కాన్ఫిగరేషన్‌లో ఉంటాయి, మరియు యాప్ ప్రాసెస్ యజమానికి ప్రత్యేక పోర్టులను ఉపయోగించడానికి అనుమతి ఉండకపోవచ్చు, కాబట్టి root గా పోర్ట్ 22 బైండ్ చేసే డెస్క్‌టాప్ అలవాటు మార్పు లేకుండా బదిలీ కాదు.

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 హ్యాండ్‌షేక్ ముందు లేదా తర్వాత విఫలమవుతుందో చూడండి. ఎప్పుడూ కనెక్ట్ కాని సాకెట్ మరియు తిరస్కరించబడిన లాగిన్ వేర్వేరు దశలు, బాధ్యులూ వేర్వేరు.

డీబగ్ చేస్తున్నప్పుడు హోస్ట్-కీ ధృవీకరణ మరియు ఖాతా పరిమితులను యథాతథంగా ఉంచండి. లిసనర్ మరియు అనుమతించిన వినియోగదారులను పరిమితం చేయడమే చేరుకోగలిగే సర్వర్‌ను ఆమోదయోగ్యం చేస్తుంది; కనెక్షన్ పని చేయాలని వాటిని సడలించడం ఒక సమస్యను అధ్వాన్నమైన దానితో మారుస్తుంది. మీ Android అమలు అదే కాన్ఫిగరేషన్ పేర్లను అనుసరిస్తే OpenSSH సర్వర్ సూచన వినడం మరియు యాక్సెస్ నియంత్రణలను కవర్ చేస్తుంది.