SSH ఫార్వర్డ్ నిజంగా ఏ యాప్ ట్రాఫిక్‌ను తీసుకువెళ్తుంది?

టెర్మినల్ కనెక్ట్ అవుతుంది, ప్రాంప్ట్ కనిపిస్తుంది, SSH యాక్సెస్ పనిచేస్తుందని అందరూ అంగీకరిస్తారు. తర్వాత ల్యాప్‌టాప్‌లోని డేటాబేస్ క్లయింట్ ఇప్పటికీ ప్రైవేట్ హోస్ట్‌ను చేరుకోలేదు, సెషన్‌పై నింద వేయబడుతుంది. నిర్మించినది ఒక షెల్, అది SSH అందించగల నాలుగు పూర్తిగా భిన్నమైన ఇంటర్ఫేస్‌లలో ఒకటి. మొదట ఇంటర్ఫేస్‌ను పేర్కొనండి, తర్వాత యాప్ నిజంగా దాన్ని ఉపయోగిస్తుందో పరీక్షించండి. క్రమం ముఖ్యం, ఎందుకంటే ప్రతి ఇంటర్ఫేస్ తనదైన విధంగా విఫలమవుతుంది.

ఏదైనా పోల్చే ముందు ఇంటర్ఫేస్‌ను పేర్కొనండి

OpenSSH క్లయింట్ మాన్యువల్ గందరగోళపరచుకోవడం సులభమైన నాలుగు యంత్రాంగాలను వేరు చేస్తుంది. షెల్ లేదా రిమోట్ కమాండ్ SSH హోస్ట్‌పై అమలవుతుంది. స్థానిక ఫార్వర్డ్ క్లయింట్‌పై వినిపించే సాకెట్‌ను తెరిచి తదుపరి కనెక్షన్‌ను రిమోట్ వైపు నుండి చేస్తుంది. రిమోట్ ఫార్వర్డ్ దీనికి విరుద్ధంగా చేస్తుంది, సర్వర్ వైపు వినిపిస్తుంది. డైనమిక్ ఫార్వర్డింగ్ దాన్ని ఎలా ఉపయోగించాలో తెలిసిన ప్రోగ్రామ్‌లకు SOCKS ముగింపు బిందువును అందిస్తుంది.

• షెల్: ప్రోగ్రామ్ రిమోట్ మెషీన్‌పై నడుస్తుంది, స్థానికంగా ఏదీ వినిపించదు.
• స్థానిక ఫార్వర్డ్: మీ ల్యాప్‌టాప్‌లో పోర్ట్ ఉంది, రిమోట్ హోస్ట్ బయటకు వెళ్లే కనెక్షన్‌ను చేస్తుంది.
• రిమోట్ ఫార్వర్డ్: రిమోట్ వైపు పోర్ట్ ఉంది, ట్రాఫిక్ మీ వైపు తిరిగి వస్తుంది.
• డైనమిక్: క్లయింట్‌పై SOCKS ప్రాక్సీ, ప్రాక్సీని అర్థం చేసుకునే యాప్‌లు మాత్రమే ఉపయోగిస్తాయి.

వీటిలో ఏదీ మార్గాన్ని ఇన్‌స్టాల్ చేయదు. ప్రాక్సీ సెట్టింగ్‌లను విస్మరించే, లేదా UDP మాట్లాడే, లేదా పేర్లను తానే పరిష్కరించే ప్రోగ్రామ్, యాక్టివ్ SSH సెషన్ ద్వారా ప్రభావితం కాదు. ఇది SSHలో లోపం కాదు; ఇది మీరు ఎంచుకున్న ఇంటర్ఫేస్ పరిధి.

స్థానిక, రిమోట్ మరియు డైనమిక్ ఫార్వర్డ్‌లు ఎవరు వినిపిస్తారనే విషయంలో భిన్నం

చాలా సందర్భాలను నిర్ణయించే భేదం వినిపించే సాకెట్ ఎవరి స్వంతమో అనేది. స్థానిక ఫార్వర్డ్‌లో క్లయింట్ వినిపిస్తుంది మరియు రిమోట్ చివర గమ్యాన్ని డయల్ చేస్తుంది, అందుకే గమ్య చిరునామా సర్వర్ దృష్టికోణం నుండి పరిష్కరించబడుతుంది. రిమోట్ ఫార్వర్డ్‌లో సర్వర్ వినిపిస్తుంది మరియు కనెక్షన్ మీ వైపు తిరిగి తీసుకువెళ్లబడుతుంది, ఈ విధంగా మీరు స్థానిక సేవను నేరుగా ప్రచురించకుండా బహిర్గతం చేస్తారు.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

మొదటి కమాండ్ ల్యాప్‌టాప్‌లో పోర్ట్ 5432ను బంధించి బాస్టియన్ నుండి కనిపించే విధంగా డేటాబేస్‌కు ఫార్వర్డ్ చేస్తుంది. రెండవది పోర్ట్ 1080లో SOCKS ప్రాక్సీని సృష్టిస్తుంది. మూడవ కమాండ్ ఏ ప్రక్రియలు నిజంగా వినిపిస్తున్నాయో నిర్ధారిస్తుంది, పోర్ట్ ఘర్షణ వల్ల నిశ్శబ్దంగా విఫలమైన బదులు ఫార్వర్డ్ ఉనికిలో ఉందనడానికి అదే ఏకైక సాక్ష్యం.

డైనమిక్ ఫార్వర్డింగ్ తనకంటూ ఒక హెచ్చరికకు అర్హం: ఇది SOCKSను గౌరవించే యాప్‌లను మాత్రమే కవర్ చేస్తుంది. బ్రౌజర్‌ను దాని వైపు మళ్లించవచ్చు, కమాండ్-లైన్ సాధనాన్ని ఉపయోగించమని చెప్పవచ్చు, కానీ స్వంత కనెక్షన్ స్టాక్ ఉన్న డేటాబేస్ డ్రైవర్ సాధారణంగా చేయలేదు. మెషీన్‌లోని ప్రతి ప్రోగ్రామ్ ఇప్పుడు టన్నెల్‌ను ఉపయోగిస్తుందని భావించడం ఈ మొత్తం రంగంలో అత్యంత సాధారణ పొరపాటు.

టన్నెల్-పరికర మోడ్ ఒక్కటే నిజమైన నెట్‌వర్క్ మినహాయింపు

OpenSSH -w టన్నెల్-పరికర ఫార్వర్డింగ్‌ను కూడా మద్దతిస్తుంది, అది TCP శ్రోతకు బదులు పాయింట్-టు-పాయింట్ ఇంటర్ఫేస్‌ను పంపుతుంది. అది నిజమైన నెట్‌వర్క్ టన్నెల్, షెల్ తెరవడం వల్ల కలిగే దుష్ప్రభావం కాదు, ఉద్దేశపూర్వకంగా కాన్ఫిగర్ చేయబడుతుంది.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

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

మీ యాప్ మీరు నిర్మించిన ఇంటర్ఫేస్‌ను ఉపయోగిస్తుందో పరీక్షించండి

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

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

మొదటి కమాండ్ హోస్ట్‌నామ్‌ను రిమోట్‌గా పరిష్కరిస్తూ SOCKS ముగింపు బిందువు ద్వారా అభ్యర్థనను పంపుతుంది, రెండవది TLS ఇంకా అవసరమైన స్థితిలో ఫార్వర్డ్ చేసిన డేటాబేస్ పోర్ట్‌ను ప్రయోగిస్తుంది. ఫార్వర్డ్ ఆపివేసిన స్థితిలో అదే పరీక్షలను నడిపించి అవి విఫలమవుతాయని నిర్ధారించుకోండి, ఎందుకంటే రెండు మార్గాల్లోనూ పాస్ అయ్యే పరీక్ష ఎప్పుడూ టన్నెల్‌ను ఉపయోగించలేదు.

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