NGINX સ્ટ્રીમ રિલે દ્વારા SSH — તોડ્યા વિના

PROXY હેડર એવા પ્રાપ્તકર્તા માટે સંદેશ છે જે તેની અપેક્ષા રાખે છે, અને પ્રોક્સી કરેલ DNS રેકોર્ડ TCP રિલે નથી. કિનારો અને અપસ્ટ્રીમ અલગ રીતે સુધારો.

રિલે દ્વારા જાહેર 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 રિલે જાહેર પરિધિમાં જાણી જોઈને કરેલું દ્વાર છે, અને તે અન્ય કોઈપણ આવક સેવા જેટલી જ સમીક્ષાને પાત્ર છે.

સંબંધિત લેખો