ఒక పరికరం కోసం రివర్స్ SSH: loopback శ్రోత లేదా రూట్ చేసిన VPN?

బయటకు మాత్రమే డయల్ చేయగల పరికరం కోసం ఒకే నిర్వహణ పోర్ట్. రివర్స్ టన్నెల్ సరిపోతుందా లేదా నిజమైన రూట్ చేసిన మార్గం అవసరమా అని మూడు షరతులు నిర్ణయిస్తాయి.

మీ పరికరం క్యారియర్ NAT వెనుక ఉంది, అది బయటకు వెళ్లే కనెక్షన్లను తెరవగలదు, ఎవరూ చేరుకోలేని SSH సర్వర్ నడుపుతుంది. వచ్చే అభ్యర్థన సాధారణంగా "దానికి VPN ఇవ్వండి" అని రూపొందించబడుతుంది, ఇది అనేక జవాబుల్లో ఒకటి. దాన్ని అంగీకరించే ముందు మీకు ఒక నిర్వాహక TCP పోర్ట్ కావాలా లేదా మొత్తం సబ్నెట్కు రూట్ చేసిన మార్గం కావాలా నిర్ణయించుకోండి, ఎందుకంటే అవి వేరే ఎక్స్పోజర్ ఉన్న వేరే ప్రాజెక్టులు.

రివర్స్ టన్నెల్ సన్నని సంస్కరణకు మంచి జవాబు చెబుతుంది. పరికరం మీ హబ్కు డయల్ చేస్తుంది, loopback పోర్ట్లో వినమని హబ్ను కోరుతుంది, ఆ పోర్ట్ను తన సొంత SSH సేవకు తిరిగి పంపుతుంది. ఆ తర్వాత నిర్వాహకులు పబ్లిక్ ఇంటర్నెట్ ద్వారా కాకుండా హబ్ ద్వారా శ్రోతను చేరుకుంటారు.

ఎంపికను నిర్ణయించే మూడు షరతులు

ఏదైనా కాన్ఫిగరేషన్కు ముందు ఇవి రాయండి. ఇవి పరిమిత నిర్వహణ ప్రవేశానికి, నెట్వర్క్ విస్తరణకు మధ్య హద్దు, వాటిని కలపడమే ఐదు వరుసల టన్నెల్ యజమాని లేని చదునైన నెట్వర్క్ అయ్యే మార్గం.

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

మూడవ వరుసే ప్రజలు వాదించేది. పరికరం SSH పోర్టుకు టన్నెల్ దాని పొరుగువారిని మీ నెట్వర్క్లో ఉంచదు, మరిన్ని ఫార్వర్డ్ల గొలుసు ద్వారా అలా కనిపించేలా చేయకూడదు. అవసరం నిజంగా LAN అయితే, అది చెప్పి బదులుగా దాన్నే రూపకల్పన చేయండి.

హబ్ వైపు: పరిమిత రిలే ఖాతా

ప్రతి పరికరానికి పబ్లిక్ కీ ప్రామాణీకరణతో, ఇంటరాక్టివ్ సెషన్ లేకుండా దాని సొంత రిలే ఖాతా ఇవ్వండి. Match ఆ ఖాతాకు పరిమితమైన బ్లాక్ అనుమతిని చిన్నదిగా ఉంచుతుంది, ప్రైవేట్ కీ అది ఉండాల్సిన పరికరంలోనే ఉంటుంది.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 ఆసక్తికరమైన వరుస. ఇది షెల్, సబ్సిస్టమ్ సెషన్లను తిరస్కరిస్తుంది, అయినా పరికరానికి అవసరమైన ఫార్వర్డింగ్ను అనుమతిస్తుంది, కాబట్టి దొంగిలించిన కీ ఇంటరాక్టివ్ లాగిన్గా మారదు. PermitListen హబ్ వైపు శ్రోత చిరునామా, పోర్ట్ను పిన్ చేస్తుంది, మరియు GatewayPorts no హబ్ ఉన్న నెట్వర్క్కు తెరవకుండా దాన్ని loopbackలో ఉంచుతుంది.

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

పరికరం వైపు: గట్టిగా విఫలమయ్యే ఫార్వర్డింగ్

పరికరం కనెక్షన్ తెరిచి శ్రోతను కోరుతుంది. ఆర్గ్యుమెంట్లోని రెండు చిరునామాలు -R వేర్వేరు అర్థాలను ఇస్తాయి, వాటిని ఎడమ నుంచి కుడికి చదవడమే ఏది ఏదో గుర్తుంచుకోవడానికి వేగవంతమైన మార్గం.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

ఎడమ జత హబ్ వినాల్సిన స్థలం. కుడి జత అభ్యర్థన వచ్చినప్పుడు పరికరం కనెక్ట్ అయ్యే లక్ష్యం, అది పరికరం సొంత వైపు నుంచి పరిష్కరించబడుతుంది. వాటిని మార్చుకుంటే శుభ్రంగా పైకి వచ్చి తప్పు స్థలానికి ఫార్వర్డ్ చేసే టన్నెల్ ఏర్పడుతుంది, ఇది వైఫల్యం కంటే దారుణం.

ExitOnForwardFailure=yes కోరిన శ్రోతను ఏర్పాటు చేయలేనప్పుడు ఆదేశాన్ని బయటకు పోయేలా చేస్తుంది, కాబట్టి రీస్టార్ట్ లూప్ సగం పనిచేసే సెషన్ను వదిలేయడం బదులు మీకు నిజం చెబుతుంది. స్థానిక SSH సేవ తర్వాత ఆరోగ్యంగా ఉందా అనే దాని గురించి ఏమీ చెప్పదు, కాబట్టి దాన్ని ప్రాసెస్ మేనేజర్తో, అప్పుడప్పుడు నిజమైన కనెక్షన్ పరీక్షతో జోడించండి.

అదనపు హాప్ తప్పించుకోవడానికి loopback వినిపించే చిరునామాను ఎప్పుడూ వైల్డ్కార్డ్తో భర్తీ చేయకండి. ఆ ఒక్క మార్పే నిర్వహణ మార్గానికి, పబ్లిక్గా చేరుకోగల పోర్టుకు మధ్య తేడా, అది సాధారణంగా డీబగ్గింగ్ సమయంలో జరిగి తర్వాత కొనసాగుతుంది. సహచరుడు హబ్ ద్వారా పోర్టును చేరుకోలేకపోతే, బైండ్ను విస్తరించడం బదులు జంప్ కాన్ఫిగరేషన్ను సరిచేయండి. ఈ రూపకల్పన పూర్తి భద్రతా వాదం loopbackే.

హబ్ ద్వారా నిర్వాహక ప్రవేశం

హబ్లో సాధారణ ఖాతా ఉన్న నిర్వాహకుడు దాని ద్వారా ఫార్వర్డ్ చేసిన పోర్టుకు దూకవచ్చు. రిలే ఖాతా దీనికి వాడబడదు, వాటిని వేరుగా ఉంచడం అర్థం అదే.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

మీరు ఎంచుకున్న ఉపనామం కింద పరికరం హోస్ట్ కీని ధృవీకరించండి, ఎందుకంటే ఆ కీ గొలుసు చివరలో పరికరాన్ని గుర్తిస్తుంది, టన్నెల్ కేవలం రవాణా. చివరి నుంచి చివరి వరకు లాగిన్ ఇప్పటికీ రెండు చివరలను ప్రామాణీకరిస్తుంది; పంచుకున్న హబ్లో ముగిసే టన్నెల్ దాన్ని దానంతట అదే విశ్వసనీయ మార్గంగా చేయదు.

జీవిత చక్రం యాజమాన్యాన్ని తీసుకోండి

పరికర ఆదేశాన్ని ప్రాసెస్ మేనేజర్ కింద సరిగ్గా ఒక క్రియాశీల ఇన్స్టాన్స్, మీరు ఉద్దేశపూర్వకంగా ఎంచుకున్న రీస్టార్ట్ విధానంతో నడపండి. keepalive ఎంపికలు చనిపోయిన భాగస్వామిని గుర్తిస్తాయి; అవి బయటకు వెళ్లిన ప్రాసెస్ను తిరిగి బ్రతికించవు.

తర్వాత డీకమిషన్ విధానాన్ని రాయండి. ప్రతి పరికరానికి దాని సొంత శ్రోత, దాని సొంత కీ లభిస్తాయి, కాబట్టి డీకమిషన్ అంటే ఆ ఖాతాను రద్దు చేయడం, ఆ కీని తొలగించడం, మొత్తం దళం పంచుకునే రహస్యాన్ని తిప్పడం కాదు.

చివరగా, loopback మీకు ఏమి ఇస్తుందో గుర్తుంచుకోండి. ఇది నెట్వర్క్ ఎక్స్పోజర్ను పరిమితం చేస్తుంది, పంచుకున్న హబ్లోని ఇతర స్థానిక వినియోగదారుల గురించి ఏమీ చేయదు, కాబట్టి హబ్ సొంత ప్రవేశ విధానం ఇప్పటికీ సరిగ్గా ఉండాలి. sshd_config సూచన పైన ఉపయోగించిన ప్రతి ఎంపికను పత్రీకరిస్తుంది, వాటిలో దేన్నైనా విస్తరించే ముందు ఫార్వర్డింగ్ విభాగాలను పూర్తిగా చదవడం విలువైనది.

సంబంధిత వ్యాసాలు