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 रिले सार्वजनिक परिधिमा जानाजान खोलिएको ढोका हो, र यो अन्य कुनै पनि आगमन सेवाजत्तिकै समीक्षाको योग्य छ।