एका उपकरणासाठी उलटा SSH: लूपबॅक श्रोता की राउटेड VPN?

फक्त बाहेर डायल करू शकणाऱ्या उपकरणासाठी एकच व्यवस्थापन पोर्ट. उलटा बोगदा पुरेशी आहे की खरा राउटेड मार्ग हवा, हे तीन अटी ठरवतात.

तुमचे उपकरण कॅरियर NAT च्या मागे आहे, ते बाहेरची जोडणी उघडू शकते, आणि असे SSH सर्व्हर चालवते जिथे कोणीही पोहोचू शकत नाही। येणारी विनंती सहसा "त्याला VPN द्या" अशी मांडली जाते, जी अनेक उत्तरांपैकी एक आहे। ती स्वीकारण्यापूर्वी ठरवा की तुम्हाला एक प्रशासकीय TCP पोर्ट हवा की संपूर्ण सबनेटपर्यंत राउटेड मार्ग, कारण ते वेगळ्या एक्स्पोजरचे वेगळे प्रकल्प आहेत।

उलटा बोगदा अरुंद आवृत्तीला चांगले उत्तर देतो। उपकरण तुमच्या हबकडे डायल करते, हबला लूपबॅक पोर्टवर ऐकण्यास सांगते, आणि तो पोर्ट आपल्या स्वतःच्या 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 हब ज्या नेटवर्कवर आहे त्यासाठी उघडण्याऐवजी तो लूपबॅकवर ठेवते।

रीलोड करण्यापूर्वी प्रभावी संरचना तपासा, आणि तसे करताना दुसरे सत्र उघडे ठेवा। 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 सेवा नंतर निरोगी आहे की नाही याबद्दल तो काहीही सांगत नाही, म्हणून त्याला प्रोसेस मॅनेजर आणि अधूनमधून खऱ्या जोडणी चाचणीसोबत जोडा।

अतिरिक्त हॉप टाळण्यासाठी लूपबॅक ऐकण्याचा पत्ता कधीही वाइल्डकार्डने बदलू नका। तो एकच बदल व्यवस्थापन मार्ग आणि सार्वजनिकरीत्या पोहोचण्याजोगा पोर्ट यांतील फरक आहे, आणि तो सहसा डीबग करताना होतो आणि मग राहतो। सहकारी हबमार्फत पोर्टपर्यंत पोहोचू शकत नसेल, तर बाइंड रुंद करण्याऐवजी जंप संरचना दुरुस्त करा। या रचनेचा संपूर्ण सुरक्षा युक्तिवाद लूपबॅक आहे।

हबमार्फत प्रशासक प्रवेश

हबवर सामान्य खाते असलेला प्रशासक त्यामार्फत फॉरवर्ड केलेल्या पोर्टवर उडी मारू शकतो। रिले खाते यासाठी वापरले जात नाही, आणि ती वेगळी ठेवण्याचा अर्थच हा आहे।

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

तुम्ही निवडलेल्या उपनावाखाली उपकरणाची होस्ट की तपासा, कारण तीच की साखळीच्या शेवटी उपकरण ओळखते आणि बोगदा फक्त वाहतूक आहे। टोकापासून टोकापर्यंतचे लॉगिन अजूनही दोन्ही टोके प्रमाणित करते; सामायिक हबवर संपणारा बोगदा त्याला स्वतःच विश्वासार्ह मार्ग बनवत नाही।

जीवनचक्राची मालकी घ्या

उपकरणाचा आदेश प्रोसेस मॅनेजरखाली नेमक्या एका सक्रिय उदाहरणासह आणि जाणीवपूर्वक निवडलेल्या रीस्टार्ट धोरणासह चालवा। कीपअलाइव्ह पर्याय मृत साथीदार ओळखतात; ते बाहेर पडलेली प्रक्रिया पुनर्जीवित करत नाहीत।

नंतर सेवानिवृत्ती प्रक्रिया लिहा। प्रत्येक उपकरणाला स्वतःचा श्रोता आणि स्वतःची की मिळते, त्यामुळे डिकमिशन म्हणजे ते खाते रद्द करणे आणि ती की काढणे, संपूर्ण ताफ्यात सामायिक रहस्य फिरवणे नाही।

शेवटी, लूपबॅक तुम्हाला काय देतो ते लक्षात ठेवा। तो नेटवर्क एक्स्पोजर मर्यादित करतो आणि सामायिक हबवरील इतर स्थानिक वापरकर्त्यांबद्दल काहीच करत नाही, म्हणून हबचे स्वतःचे प्रवेश धोरण अजूनही बरोबर असले पाहिजे। sshd_config संदर्भ वर वापरलेल्या प्रत्येक पर्यायाचे दस्तऐवजीकरण करते, आणि त्यांपैकी कोणताही रुंद करण्यापूर्वी फॉरवर्डिंग विभाग पूर्ण वाचण्यासारखे आहेत।

संबंधित लेख