ஒரு கிளவுட் சேவைக்கான சொந்த TLS, SSH அனுப்புதல் அல்லது VPN

இரண்டு கிளவுட் இயந்திரங்களுக்கு இடையே எதையாவது மறையாக்க வேண்டுமா என்பது அரிதாகவே கேள்வி; எந்த இடைமுகத்தை மறையாக்குகிறீர்கள், யார் யாருடைய அடையாளத்தைச் சரிபார்க்கிறார் என்பதே கேள்வி. இந்த உரையாடல்களை நெட்வொர்க் வரைபடத்திலிருந்து அல்ல, சேவையிலிருந்து தொடங்குகிறேன், ஏனெனில் சேவைக்கு என்ன தேவை என்பது ஏற்கனவே தெரியும். மூன்று எல்லைகள் பெரும்பாலான நிலைகளை உள்ளடக்குகின்றன: பயன்பாட்டின் சொந்த TLS, SSH வழியாக அனுப்பப்படும் ஒரு TCP போர்ட், மற்றும் ஒவ்வொரு பங்கேற்பாளருக்கும் முகவரி தரும் வழிமாற்றப்பட்ட மேலடுக்கு. அவை வலிமையின் அடிப்படையில் அல்ல, சிக்கலின் எவ்வளவு பகுதியை உள்ளடக்குகின்றன என்பதன் அடிப்படையில் வரிசைப்படுத்தப்படுகின்றன.

நெட்வொர்க்கிலிருந்து அல்ல, சேவையிலிருந்து தொடங்குங்கள்

செயல்முறையிலிருந்து வெளியே செல்லுங்கள். எந்த நெறிமுறையில் பேசுகிறது, கிளையண்ட் எந்தப் பெயரைச் சரிபார்க்கும், யாருக்கு இணைப்பைத் திறக்க அனுமதி உண்டு? அந்த மூன்று பதில்களும் எந்த ஒப்பீட்டு அட்டவணையையும் விட வேகமாக விருப்பங்களை நீக்குகின்றன, சேவையின் சொந்த உள்ளமைவு பொதுவாக சில நிமிடங்களில் அவற்றுக்குப் பதிலளிக்கிறது.

8443 போர்ட்டில் ஏற்கனவே HTTPS வழங்கும் ஒரு சிறிய உள் API எடுத்துக் கொள்ளுங்கள், api.internal.example க்கான சான்றிதழுடன். ஹோஸ்ட்டில் ss -ltnp அது எதனுடன் பிணைக்கப்பட்டுள்ளது என்பதைக் காட்டுகிறது, openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example சான்றிதழ் கிளையண்ட் உண்மையில் பயன்படுத்தும் பெயருக்குச் செல்லுபடியாகுமா என்பதைக் காட்டுகிறது. இரண்டும் ஆரோக்கியமாக இருந்தால், சேவை தன் சொந்த ஓட்டத்தைப் பாதுகாக்க முடியும், எஞ்சியிருப்பது அணுகல் திறன் மட்டுமே. இது நெட்வொர்க் கட்டுவதை விட மிகச் சிறிய சிக்கல்.

படி 1: சேவை தன்னைத் தானே பாதுகாக்கிறதா?

இது பொருந்தும்போது தேர்ந்தெடுக்க வேண்டிய விருப்பம், குழுக்கள் கருதுவதை விட அடிக்கடி பொருந்துகிறது. சேவையின் மறையாக்கம் கிளையண்ட் மற்றும் சேவையகத்திற்கு இடையிலான முழுப் பாதையையும், இடையிலான ஒவ்வொரு தாவலையும் உள்ளடக்கியது, நடுப்பகுதியைச் சுற்றியுள்ள எந்தச் சுரங்கப்பாதையும் அதை மேம்படுத்தாது. கிளையண்டின் இயல்புநிலைச் சேமிப்பில் தற்செயலாக இருப்பதை நம்புவதற்குப் பதிலாக எதிர்பார்க்கப்படும் பெயரையும் நம்பிக்கையையும் வெளிப்படையாக அமைக்கவும்.

மறையாக்கமும் அணுகல் திறனும் தனித்தனிக் கட்டுப்பாடுகளாகவே இருக்கின்றன, அவற்றை இணைப்பதே இந்த விருப்பம் தவறாகும் இடம். வரம்பற்ற பொது லிசனரில் உள்ள TLS சேவை இன்னும் யாரிடமிருந்தும் இணைப்பு முயற்சிகளை ஏற்கிறது, எனவே லிசனரும் நெட்வொர்க் விதிகளும் பேலோட் பாதுகாக்கப்படுகிறது என்பதிலிருந்து சுயாதீனமாக வரையறுக்கப்பட வேண்டும். பின்னர் சார்புகளைச் சரிபார்க்கவும், ஏனெனில் TLS மேலான API கண்டறிதல் முடிவுப்புள்ளி, நிர்வாகப் போர்ட் அல்லது பக்கத்தில் உள்ள மொத்தப் பரிமாற்றச் சேனல் பற்றி எதுவும் கூறவில்லை. ஒவ்வொன்றுக்கும் அதன் சொந்த பதில் தேவை, பாதுகாக்கப்படாத ஒரு சகோதரர் முழு எல்லையையும் கற்பனையாக்கப் போதுமானது.

படி 2: ஒரு TCP போர்ட்டே முழுத் தேவையா?

தேவை உண்மையில் ஒரு TCP போர்ட் என்றால், அனுப்புதல் வேலை செய்யும் மிகச் சிறிய விஷயம். SSH உள்ளூர் அனுப்புதல் அந்தப் போர்ட்டை ஏற்கனவே உள்ள அங்கீகரிக்கப்பட்ட இணைப்பின் வழியாகக் கொண்டு செல்கிறது.

வடிவம் ssh -N -L 8443:127.0.0.1:8443 [email protected], முக்கியமான விவரம் இலக்கு முகவரி: 127.0.0.1 தொலைப் பக்கத்தில் தீர்க்கப்படுகிறது, எனவே சேவைக்கான இணைப்பு உங்கள் மடிக்கணினியிலிருந்து அல்ல, பாஸ்டியனிலிருந்து திறக்கப்படுகிறது. உள்ளூர் லிசனரை -L 127.0.0.1:8443:... ஆக இறுக்கமாகப் பிணைக்கவும், தற்செயலாக சேவையை உங்கள் சொந்த உள்ளூர் நெட்வொர்க்கில் வெளியிடாமல் இருக்க. சேவையகப் பக்கத்தில், கிளையண்டின் நல்ல நடத்தையை நம்புவதற்குப் பதிலாக கணக்கு எதை அனுப்பலாம் என்பதை வரம்பிடுங்கள். PermitOpen, AllowTcpForwarding local மற்றும் GatewayPorts no இயல்புநிலை — பொது ரிலேவை குறிப்பிட்ட சேனலாக மாற்றும் மூன்று அமைப்புகள்.

ஒப்பந்தம் இரு திசைகளிலும் குறுகலானது. SSH தன் சொந்த சேனலைப் பாதுகாக்கிறது, பாஸ்டியனிலிருந்து மற்றொரு பயன்பாட்டிற்கான அடுத்த தாவலுக்கு அதன் சொந்தப் பாதுகாப்பு தேவை. பாஸ்டியனின் loopback இல் மட்டும் கேட்கும் சேவையின் வெளிப்பாடு மற்றொரு நெட்வொர்க் வழியாக அடையும் சேவையிலிருந்து முற்றிலும் வேறுபட்டது, அனுப்புதல் அதை மாற்றாது. சுரங்கப்பாதையை அவற்றின் மாற்றாகக் கருதாமல் பயன்பாட்டின் அங்கீகாரமும் TLS சோதனைகளும் வைத்திருங்கள்.

ஒரு உரிமையாளருடன் ஒரு இணைப்புக்கு இது நன்றாக வேலை செய்கிறது. பெரிய அளவில் இது ஒரு அமைப்பாக மாறுகிறது: உள்ளூர் போர்ட் மோதல்கள், மேற்பார்வை, விசை சுழற்சி மற்றும் மறுதொடக்கத்திற்குப் பிறகு அனுப்புதலை யார் மீண்டும் தொடங்குகிறார் என்ற கேள்வி.

படி 3: வழிமாற்றமே உண்மையான தேவையா?

அந்தப் பட்டியல் சிறிய விருப்பத்தின் நேர்மையான விலை, அதனால்தான் குழுக்கள் இறுதியில் மறந்துபோன சில பின்னணி கட்டளைகளை நிர்வகிக்கப்படும் ஒன்றால் மாற்றுகின்றன. மாற்றீடு தானாகவே VPN அல்ல. தேவை இன்னும் ஒரு TCP போர்ட் என்றால், ஆவணப்படுத்தப்பட்ட உரிமையாளருடன் கண்காணிக்கப்படும் அனுப்புதல் மேலடுக்கை விட மலிவாக இயங்கும், நீங்கள் பார்க்கக்கூடிய வழிகளில் தோல்வியடைகிறது. நேர்த்தியை அளப்பதற்கு முன் செயல்பாட்டு உரிமையை அளவிடுங்கள்.

வழிமாற்றமே தேவையாக இருக்கும்போது வழிமாற்றம் சரியான பதிலாகிறது. சாதாரண IP இணைப்பு தேவைப்படும் பல பயன்பாடுகள், TCP அனுப்புதல் கொண்டு செல்ல முடியாத நெறிமுறைகள் அல்லது ஹோஸ்ட்களுக்கு இடையே நகரும் சேவைகள் — அனைத்தும் ஒரே திசையைக் காட்டுகின்றன.

மேலடுக்கு பங்கேற்பாளர்களுக்கு முகவரியையும் பாதையையும் தருகிறது, பின்னர் உண்மையான வேலை தொடங்குகிறது: ஒன்றுடன் ஒன்று கூடாத வரம்புகள், பாதை உரிமை, DNS, பதிவு, ரத்து மற்றும் இணை மறைந்தால் என்ன நடக்கும். இவற்றில் எதுவும் முகவரியுடன் வருவதில்லை. மேலடுக்கில் ஏற்கப்பட்ட இணையும் இலக்கில் ஒவ்வொரு செயல்பாட்டிற்கும் தானாக அங்கீகரிக்கப்படவில்லை, எனவே சேவை-நிலை அங்கீகாரம் நீடிக்கிறது.

பின்னர் உங்களிடம் இருப்பது

நீங்கள் விட்டுச் செல்லும் பதிவில் இரண்டு விஷயங்கள் அடங்கும். முதலாவது கிளையண்ட் சரிபார்க்க வேண்டிய அடையாளம், ஏனெனில் எதையாவது வேலை செய்ய வைக்க பெயர்ச் சரிபார்ப்பு தளர்த்தப்பட்டால் இந்த எல்லைகள் ஒவ்வொன்றும் அமைதியாக மோசமாகும். இரண்டாவது அகற்றும் படி: அணுகல் முடிந்ததும் எந்த விசை, எந்த விதி அல்லது எந்தப் பாதை மறைகிறது, அதை யார் செய்கிறார்.

இந்தப் பயணம் தொடங்கிய இடத்திலேயே, சேவையில் முடிகிறது. உண்மையான போக்குவரத்தை உள்ளடக்கி, நீங்கள் சரிபார்க்க நினைத்த இணைகளைச் சரிபார்க்கும் எல்லையைத் தேர்ந்தெடுத்து, பின்னர் அணுகல் எவ்வாறு புதுப்பிக்கப்படுகிறது, கண்காணிக்கப்படுகிறது, அகற்றப்படுகிறது என்பதை எழுதுங்கள். OpenSSH குறிப்பு குறுகிய ஒப்பந்தத்தை உறுதியளிக்கும் முன் அனுப்புதல் விருப்பங்களை உறுதிப்படுத்தும் இடம். அகற்றும் படியை ஒரு வாக்கியத்தில் விவரிக்க முடியாவிட்டால், எல்லை சிக்கலை விடப் பெரியது.