NGINX स्ट्रीम रिलेमधून SSH — न तोडता

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

दोन सीमा, दोन लक्षणे

किनाऱ्यावरील अपयश असे दिसते की जिथे SSH बॅनर असायला हवा तिथे HTTP स्थिती पृष्ठ येत आहे। कनेक्शन TCP स्तरावर पूर्ण होते आणि पहिले बाइट वेब सर्व्हरचा मजकूर असतात। ही प्रोटोकॉल विसंगती आहे, हरवलेला पॅकेट नाही। किनारा त्या नावासाठी जाणीवपूर्वक दुसरे काहीतरी सेवा देत आहे हेही ते सांगते।

अपस्ट्रीममधील अपयश वेगळे दिसते। कनेक्शन sshd पर्यंत पोहोचते, sshd ला अपेक्षित असलेली ओळख देवाणघेवाण नसलेले बाइट वाचते, आणि सत्र कधीही की न देता मरते किंवा अडकते।

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

PROXY हेडर हा संदेश आहे, स्विच नाही

स्ट्रीम मॉड्यूलमध्ये, proxy_protocol on NGINX ला पेलोडपूर्वी अपस्ट्रीमच्या दिशेने PROXY प्रोटोकॉल हेडर लिहिण्याची सूचना देतो। ते TCP प्रॉक्सी सक्षम करत नाही, आणि त्याचा SSH एन्क्रिप्शनशी काही संबंध नाही। ही प्राप्तकर्त्यास उद्देशून टीप आहे। प्राप्तकर्त्याला ते वाचता येत नसेल, तर ते स्ट्रीमच्या सुरुवातीला कचरा बनते।

प्राप्त करणाऱ्या सेवेने ते हेडर जाणीवपूर्वक वापरायला हवे। सामान्य sshd कनेक्शनवरील पहिले बाइट म्हणून SSH ओळख देवाणघेवाणीची अपेक्षा करतो, म्हणून अनपेक्षित प्रस्तावना हात मिळवणी खराब सर्व्हरसारखी दिसेल अशा पद्धतीने तोडते।

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

तो तुकडा VPN द्वारे पोहोचण्यायोग्य बॅकएंडसाठी संपूर्ण कार्यरत रिले आहे। कोणतीही PROXY सूचना दिसत नाही कारण प्राप्तकर्ता तो प्रोटोकॉल बोलत नाही, आणि ती अनुपस्थिती वगळणे नाही, एक निर्णय आहे।

दोन्ही दिशाही वेगळ्या करा। listen ओळीवर proxy_protocol सेट करणे म्हणजे NGINX ला अपेक्षा आहे की त्याचा स्वतःचा क्लायंट आधी हेडर पाठवेल; सामान्य SSH क्लायंटसाठी ते सक्षम केल्यास लोक सहसा सोडवू पाहत असलेल्या समस्येच्या अगदी उलट घडते।

सार्वजनिक होस्टनाम प्रत्यक्षात कुठपर्यंत पोहोचते

SSH सत्रातील HTTP 400 पृष्ठ किनाऱ्याबद्दलचा पुरावा आहे। मार्गात काहीतरी HTTP बोलते, आणि बॅकएंडवरील की किंवा खात्याचे कितीही काम ते बदलणार नाही। किनारा निकाली निघेपर्यंत बॅकएंड बदलणे थांबवा।

Cloudflare चा सामान्य प्रॉक्सी केलेला रेकॉर्ड त्याचा समर्थित HTTP आणि HTTPS रहदारी निर्धारित पोर्टवर वाहतो। होस्टनामासाठी प्रॉक्सी चालू केल्याने सामान्य TCP रिले तयार होत नाही, आणि SSH पोर्ट 443 वर हलवल्याने ते HTTPS होत नाही।

दोन व्यवहार्य दिशा आहेत। केवळ DNS रेकॉर्ड तुमच्या स्वतःच्या TCP रिलेकडे निर्देश करू शकतो, ज्यामुळे उघड होण्याचा निर्णय तुमच्या हाती राहतो। किंवा, SSH वहन स्पष्टपणे नोंदवणारे उत्पादन वापरा, त्याच्या स्वतःच्या ओरिजिन, क्लायंट आणि प्रवेश संरचनेसह।

तुम्ही काहीही निवडा, रिलेला अजूनही बॅकएंडपर्यंत VPN मार्ग, परवानगी असलेले कनेक्शन आणि परतावा मार्ग आवश्यक आहे। सार्वजनिक बाजू कार्यरत असल्यामुळे मार्ग ऐच्छिक नाही।

उपनावाने SSH ओळख स्थिर ठेवा

वापरकर्ते सहसा त्यांचे विद्यमान होस्टनाम टाइप करत राहू इच्छितात। SSH संरचनेतील उपनाव रिलेबद्दल काहीही न बदलता ते करू शकते, आणि बदल क्लायंटच्या बाजूला ठेवते जिथे तो असायला हवा।

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

HostKeyAlias नसल्यास, OpenSSH तो ज्या नावाने जोडतो त्याच्या खाली होस्ट की शोधतो, त्यामुळे नोंद हलते आणि प्रत्येक वापरकर्त्याला पहिल्या वापरात की बदलल्याचा इशारा दिसतो। उपनाव सेट केल्यास known-hosts नोंदी स्थिर राहतात आणि कनेक्शन अजूनही रिलेकडे जाते।

हे उपनाव केवळ SSH-आधारित दूरस्थ संग्रहांना लागू आहे। HTTPS Git URL ते पाहत नाही, आणि सामान्य दूरस्थ URL तुम्ही प्रत्यक्षात तयार केलेल्या वाहनाशी जुळले पाहिजे।

तुम्ही जे करू नये ते म्हणजे इशारा जाण्यासाठी होस्ट की सत्यापन बंद करणे। त्यामुळे फॉरवर्डिंग दुरुस्तीने कधीही स्पर्श करायला न सांगितलेले संरक्षण काढून टाकले जाते, आणि दिसणारी गैरसोय खऱ्या उघडपणात बदलते।

प्रत्येक हॉप स्वतंत्रपणे सत्यापित करा

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

प्रत्येक निकालासोबत गंतव्य पत्ता, पोर्ट आणि पहिले प्रोटोकॉल बाइट ठेवा। हा त्रिकूट किनाऱ्याची त्रुटी VPN मार्गक्रमण समस्या आणि SSH प्रमाणीकरण अपयशापासून वेगळी करतो, आणि तोच दुरुस्ती व अंदाज यातील फरक आहे।

शेवटी, इच्छित उघडपणाची नोंद करा। खाजगी बॅकएंडपर्यंत SSH वाहणारा TCP रिले सार्वजनिक परिघात जाणीवपूर्वक केलेले द्वार आहे, आणि तो इतर कोणत्याही आवक सेवेइतकाच आढावा घेण्यास पात्र आहे।