HAProxy के साथ डोमेन पर आधारित SSH ट्रैफ़िक को रूट करें

Question

मैं वर्तमान में घर पर अपने छोटे क्लस्टर का निर्माण कर रहा हूं और मैं HAProxy के साथ काम करने के लिए SSH रूटिंग (लोड संतुलन) प्राप्त करने की कोशिश कर रहा हूं। मुझे पता चला है कि HTTP ट्रैफ़िक को कैसे रूट किया जाए लेकिन मैं SSH के साथ संघर्ष कर रहा हूँ। मुझे तुरंत टीसीपी प्रोटोकॉल के बारे में पर्याप्त जानकारी नहीं है कि मुझे क्या देखना है, ताकि मैं यह निर्धारित कर सकूं कि मैं किसी होस्ट के लिए किसी कनेक्शन के लिए क्वेरी कैसे कर सकता हूं (यह सुनिश्चित नहीं है कि कनेक्शन में कहीं और भी है) या बस कुछ भी जो पहचान करेगा मुझे कौन सा सर्वर एसएसएच में चाहिए।

दस्तावेज़ में SSH ट्रैफ़िक का बार-बार उल्लेख किया गया है ताकि कुछ ऐसा हो जो मुझे याद न हो। मैं अलग-अलग बंदरगाहों का उपयोग करके अलग-अलग बंदरगाहों का उपयोग नहीं करना चाहता हूं क्योंकि वे मानक नहीं हो सकते हैं इसलिए सार्वजनिक नेटवर्क या अन्य सामान पर रोक नहीं है जो मुझे प्रतिबंधित करेगा।

मेरा वर्तमान सेटअप इस तरह दिखता है:

मेरे डोमेन (या आईपी) पर अनुरोध - & gt; राउटर - & gt; पोर्ट के आधार पर NAT आगे - & gt; HAProxy उस पोर्ट पर सुन रहा है - & gt; अब उस ट्रैफ़िक की पहचान करनी चाहिए जो एक निश्चित सर्वर के लिए समर्पित है और इसके प्रति प्रॉक्सी ट्रैफ़िक है।

संपादित करें: जैसा कि Cha0s ने साफ़ किया है कि यह SSH (या एक जैसे) के साथ संभव नहीं है।

यदि आप एक अलग विधि में रुचि रखते हैं तो स्वेन का जवाब कुछ ऐसा ही करने में अच्छी जानकारी देता है, लेकिन अलग-अलग उप-डोमेन अलग-अलग सार्वजनिक स्थैतिक क्षेत्रों के लिए हल करते हैं

Comments

आप SSH ट्रैफ़िक को रूट क्यों करना चाहते हैं और इस उद्देश्य के लिए HA क्यों?

— 030

क्योंकि मेरे पास एक ही आईपी के पीछे कई मशीने हैं (मैक मिनी कर रही ईमेल n सामान रास्पबेरी पी 2 जिटलैब के साथ)। यह एक स्थिर आईपी है जिसका मैं भुगतान करता हूं लेकिन मेरे लिए दूसरा रास्ता नहीं है। मैं संभावित आईपी से विवश हूं

— Constantin Jacob

Answer 1

मेरा मानना ​​है कि आप शर्तों को मिला रहे हैं।

लोड संतुलन आमतौर पर मतलब है कि आप एक मेजबान से कनेक्ट करें ( example.com ) और लोड बैलेंसर को एक या एक से अधिक बैकएंड मेजबानों को सभी कनेक्शन वितरित करने दें, आमतौर पर उपयोगकर्ता नियंत्रण के बिना जिस वास्तविक होस्ट से आप जुड़ते हैं। यह आसानी से विभिन्न तरीकों से एसएसएच के लिए किया जा सकता है।

कुछ प्रोटोकॉल, जैसे HTTP के साथ Host हेडर, लोड बैलेंसर को यह तय करने के लिए अधिक जानकारी दे सकता है कि कौन से बैकएंड सर्वर से कनेक्शन को रूट किया जाना चाहिए (उदा। example.com के पास जाता है a तथा b, जबकि example.org के पास जाता है c तथा d )।

SSH के पास ऐसा कोई क्षेत्र नहीं है और इसलिए, यह लोड बैलेंसर और केवल एक IP पते के साथ नहीं किया जा सकता है। यह इस कार्य के लिए एक LB अनुपयुक्त बनाता है।

आमतौर पर, यह SSH प्रॉक्सी / गेटवे / जंप होस्ट के रूप में होस्ट का उपयोग करके हल किया जाता है और अपने SSH क्लाइंट को इसे इस तरह उपयोग करने का निर्देश देता है। यदि आप OpenSSH का उपयोग करते हैं, तो अपने ग्राहकों में निम्नलिखित डालें ~/.ssh/config

Host  *.internal.lan
   ProxyCommand ssh -q -A  -x proxy.example.com -W %h:%p

अब, यदि आप में सूचीबद्ध नामों से जुड़ते हैं Host लाइन, आपका SSH क्लाइंट पहले कनेक्ट करेगा proxy.example.com (जो आपके सार्वजनिक आईपी पते की ओर इशारा करता है) और इसे वास्तविक मशीन के लिए गेटवे के रूप में उपयोग करें (यदि लागू हो तो अपने वास्तविक प्रॉक्सी मशीन के 22 को पोर्ट करने के लिए एनएटी पोर्ट का उपयोग करें)। ध्यान दें कि proxy.example.com हल करने में सक्षम होना चाहिए *.internal.lan। या तो एक DNS सर्वर सेटअप करें या इसे प्राप्त करने के लिए अपने राउटर द्वारा प्रस्तुत आंतरिक एक का उपयोग करें।

उसके बाद, एक बाहरी नेटवर्क से जिसे आप कनेक्ट करते हैं nas.internal.lan अपने NAS (या) तक पहुँचने के लिए raspi.internal.lan आदि ...), और आपके स्थानीय नेटवर्क के अंदर से आप अभी उपयोग करते हैं nas या raspi (इसलिए कनेक्शन प्रत्यक्ष है और गेटवे के माध्यम से नहीं है)।

एक और तरीका है, इस तथ्य को देखते हुए कि आप NAT का उपयोग करते हैं:

अपने NAT राउटर में पोर्ट फ़ॉरवर्डिंग बनाएं, उदा। पसंद

Port 2210 -> internal host1, port 22
Port 2211 -> internal host2, port 22

और फिर अपने ग्राहकों में निम्नलिखित डाल दिया ~/.ssh/config:

Host host1.example.com  
   Port 2210

Host host2.example.com 
   Port 2211

और सुनिश्चित करें host1/2.example.com दोनों आपके बाहरी आईपी पते की ओर इशारा करते हैं।

तो आप बस SSH के माध्यम से कनेक्ट कर सकते हैं host1.example.com और OpenSSH 2210 पोर्ट से कनेक्ट होगा, जो NAT गेटवे द्वारा आपके इंटरल होस्ट 1 को आगे बढ़ाया जाता है।

दोनों विधियाँ आपके परिदृश्य में काम करती हैं।

Comments

जवाब के लिए धन्यवाद। यदि आप मेरे प्रश्न के तहत मेरी अंतिम टिप्पणी को देखेंगे तो आप देखेंगे कि यह मेरे लिए क्यों संभव नहीं है। मैं आपके उत्तर को वैसे भी बढ़ा दूंगा क्योंकि यह अच्छी जानकारी देता है।

— Constantin Jacob

यह सच नहीं है। मेरे पास एक समान सेटअप है और यह निर्दोष काम करता है।

— Sven

लेकिन अगर ये सभी उपडोमेन और होस्ट आईपी का सामना करने वाली एक ही जनता के लिए हल करते हैं, तो मुझे अभी भी समस्या है कि मैं बंदरगाहों को छोड़कर ट्रैफिक की पहचान नहीं कर सकता हूं जो मैं पहले से बताए गए कारणों (मानक बंदरगाहों आदि का उपयोग करना) के कारण नहीं चाहता हूं। ..)

— Constantin Jacob

मैंने आपको इस समस्या को हल करने का एक तरीका दिखाया है। यह करना आसान है और मैं इसका उपयोग हर समय सैकड़ों मशीनों से जुड़ने के लिए करता हूं, दोनों काम पर और घर पर। यदि आप जोर देते हैं कि यह HTTP के साथ काम करता है, तो आप भाग्य से बाहर हैं।

— Sven

ठीक है। मुझे यकीन ही नहीं हो रहा था कि हम दोनों एक दूसरे को पॉइंट्स याद कर रहे हैं। मैं आज रात आपके सेटअप की कोशिश करूंगा

— Constantin Jacob

Answer 2

AFAIK आप डोमेन के आधार पर ऐसा नहीं कर सकते। HTTP ऐसा काम कर सकता है क्योंकि इसमें एक विशेष है Host हेडर जिसे ब्राउज़र (इस मामले में एक रिवर्स प्रॉक्सी) समझ सकते हैं और इसके आधार पर निर्णय ले सकते हैं।

अन्य टीसीपी प्रोटोकॉल पर मुझे कुछ भी समान नहीं है। निश्चित तौर पर एसएसएच पर नहीं।

Comments

तो SSH रूटिंग (भार संतुलन) निश्चित रूप से असंभव है?

— Constantin Jacob

Answer 3

तो, आम तौर पर बोल, हाँ, केवल HTTP HAProxy में गंतव्य hostname निर्धारित कर सकते हैं ... हालांकि, अगर TCP क्लाइंट HAProxy से कनेक्ट कर रहा है तो गंतव्य पता (IP या FQDN) भेजता है, यह है उस जानकारी को स्क्रैप करना और रूटिंग प्रयोजनों के लिए इसका उपयोग करना संभव है।

मैं अपना Minecraft साझा-पोर्ट पोकर डीलर प्रस्तुत करता हूं:

#starting from top of file, for completeness.
    global
       user haproxy
       group haproxy
#setting tcp mode here is required, won't work if in frontend area!
    defaults
       mode tcp
#setting up the HAProxy listener:
    frontend frontend-name
       bind :25565
       tcp-request inspect-delay 3s
#ACLs for 1.9 and newer clients:
        acl mojang req.payload(5,16) -m sub sub1.domain.tld1
        acl bungee req.payload(5,16) -m sub sub2.domain.tld1
        acl bungee req.payload(5,16) -m sub sub1.domain.tld2
        acl nukkit req.payload(5,16) -m sub sub3.domain.tld1
#ACLs for 1.8 and older clients, keeping pinger working:
        acl mojang req.payload(4,16) -m sub sub1.domain.tld1
        acl bungee req.payload(4,16) -m sub sub2.domain.tld1
        acl bungee req.payload(4,16) -m sub sub1.domain.tld2
        acl nukkit req.payload(4,16) -m sub sub3.domain.tld1
#Accept connections if matching an ACL above:
        tcp-request content accept if bungee
        tcp-request content accept if mojang
        tcp-request content accept if nukkit
#Route connection to appropriate backend server:
        use_backend minecraft.bungee if bungee
        use_backend minecraft.mojang if mojang
        use_backend minecraft.nukkit if nukkit
#backend servers - one bungee network, one notchian server, one nukkit server:
    backend minecraft.bungee
    #here we're directing the connection to bungee on 127.0.0.1:25566
    #We're also sending the proxy-protocol(v2) to bungee (check conf!)
       server bungee-server 127.0.0.1:25566 send-proxy-v2
    backend minecraft.mojang
    #Mojang servers can't use the proxy-procotol, so not sending it
       server mojang-server 127.0.0.2:25567
    backend mincraft.nukkit
    #nukkit will never work here, as Bedrock is based on UDP, not TCP!
       server sponge-server 127.0.0.3:25568
#EoF

यह है एक बुनियादी सेटअप, और काम करता है। मेरे सेटअप की आवश्यकता वाले विकल्पों का उपयोग करते हुए मेरा इन-प्रोडक्शंस सेटअप काफी अलग है।

अब, यह बस नीचे आता है - क्या आप पैकेट में गंतव्य होस्ट ढूँढ सकते हैं ताकि आप इसे HAProxy के पेलोड के साथ देख सकें?