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 ரிலே பொது சுற்றளவில் வேண்டுமென்றே திறக்கப்பட்ட திறப்பு, அது வேறு எந்த உள்வரும் சேவையையும் போலவே அதே மறுஆய்வுக்குத் தகுதியானது.