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 റിലേ പൊതു പരിധിയിൽ ബോധപൂർവം തുറന്ന ദ്വാരമാണ്, മറ്റേതൊരു ഇൻബൗണ്ട് സേവനത്തിനും അർഹതയുള്ള അതേ പരിശോധനയ്ക്ക് അതും അർഹമാണ്.