ஒரு Mac திரைக்கு உள்ளூர் SSH அனுப்பீடா அல்லது முழு VPN-ஆ?

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

மூன்று நிபந்தனைகள் இதைத் தீர்மானிக்கின்றன, அவற்றில் எதுவும் உங்களை நிர்வகிக்கப்படும் VPN நோக்கித் தள்ளலாம்.

மூன்று நிபந்தனைகள் இதைத் தீர்மானிக்கின்றன

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

பதில்கள் «ஒன்று», «ஆம்» மற்றும் «நான், தற்போதைக்கு» எனில், அனுப்பீடே சரியான கருவி. ஏதேனும் பதில் மாறினால், ஆதரவுடன் கூடிய தொலை அணுகல் வடிவமைப்பு ஒரு வருடத்தில் ஆவணப்படுத்தப்படாத சுரங்கப்பாதையைத் தொடரும் சம்பவ மதிப்பாய்வை விட மலிவானது.

ஒரு போர்ட்டை அனுப்புங்கள், வலையமைப்பை அல்ல

உள்ளூர் அனுப்பீடு உங்கள் இயந்திரத்தில் ஒரு கேட்பானைத் திறந்து ஒவ்வொரு இணைப்பையும் SSH சேவையகம் வழியாக அது அடையக்கூடிய இலக்குக்கு அனுப்புகிறது. திரைப் பகிர்வுச் சேவை TCP 5900-இல் கேட்கும் Mac-க்கும், mac.corp.example தீர்க்கக்கூடிய பாஸ்டியனுக்கும், கட்டளை குறுகியதும் வேண்டுமென்றே குறுகலானதும் ஆகும். அதிலுள்ள ஒவ்வொரு விருப்பமும் ஏற்பாட்டைச் சிறியதாக வைத்திருக்க உள்ளது: ஷெல் இல்லை, அனைத்து இடைமுகங்களிலும் கேட்பான் இல்லை, டீமன் இல்லை. அதைச் சமையல் குறிப்பாக அல்ல, எல்லையின் அறிக்கையாகப் படியுங்கள்.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

கேட்பானை 127.0.0.1-இல் கட்டுவது அதை மற்ற எல்லா இடைமுகங்களிலிருந்தும் விலக்கி வைக்கிறது. இது முறையல்ல: எல்லா இடைமுகங்களிலும் கட்டப்பட்ட அனுப்பீடு உங்கள் மடிக்கணினியை அதே கஃபே Wi-Fi-இல் உள்ள எவருக்கும் நிறுவன வலையமைப்பிற்குள் திறந்த ரிலேயாக மாற்றுகிறது. போர்ட் ஏற்கனவே பயன்பாட்டில் இருந்தால், மற்றொரு உயர்ந்த போர்ட்டைத் தேர்ந்தெடுத்து பார்வையாளரைப் புதுப்பிக்கவும்; உதாரணம் பொருந்தும் என்று தொடர்பில்லாத சேவையை நிறுத்த வேண்டாம்.

பாஸ்டியனில் உள்ள கணக்கிற்கும் அந்த இலக்குக்கு அனுப்ப அனுமதி தேவை. சில கடினமான SSH கட்டமைப்புகள் போர்ட் அனுப்பீட்டை முழுவதுமாக முடக்குகின்றன, சில permit-listen அல்லது permit-open உத்தரவால் கட்டுப்படுத்துகின்றன. மறுக்கப்பட்ட சேனல் என்றால் கடவுச்சொல் தவறு என்று கருதுவதற்கு முன் சேவையகக் கொள்கையைப் படியுங்கள்.

SSH எதை என்க்ரிப்ட் செய்கிறது, எங்கே நிற்கிறது

SSH அமர்வு உங்கள் Mac-இல் இருந்து பாஸ்டியன் வரையிலான போக்குவரத்தைப் பாதுகாக்கிறது, அனுப்பீடு VNC நெறிமுறையைப் புரிந்துகொள்ளாமல் அந்த அமர்வுக்குள் கொண்டு செல்கிறது. இணைப்பு பாஸ்டியனை விட்டு இலக்கை நோக்கிச் சென்றதும், அது இனி உங்கள் SSH அமர்வுக்குள் இல்லை. அந்தக் கடைசித் தாண்டலில் எந்தப் பாதுகாப்பு இருந்தாலும், அது இலக்கு நெறிமுறைக்கும் தனியார் வலையமைப்பின் சொந்தக் கட்டுப்பாடுகளுக்கும் உரியது.

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

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

முழு VPN எப்போது சரியான முடிவு

பணிக்கு ஒன்றுக்கு மேற்பட்ட போர்ட் தேவைப்பட்டால் VPN தேர்ந்தெடுங்கள்: Apple Remote Desktop-இன் நிர்வாகம் மற்றும் அறிக்கை செயல்பாடுகள் ஒரு TCP அனுப்பீடு கொண்டு செல்ல முடியாத கூடுதல் TCP மற்றும் UDP போக்குவரத்தைப் பயன்படுத்துகின்றன. அனுப்பீடு முழு தயாரிப்பின் பகுதி செயலாக்கம் அல்ல; அது வேறு, சிறிய கருவி.

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

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

அனுப்பீடு சத்தமாகத் தோல்வியடையட்டும்

தோல்வியடைந்த கட்டுத்தளம் அமர்வை நிறுத்த, இணைந்ததுபோல் தோன்றி எதையும் அனுப்பாத ஷெல்லை விட்டுச் செல்லாமல் இருக்க ExitOnForwardFailure=yes பயன்படுத்துங்கள். புரவலன் விசைச் சரிபார்ப்பை இயக்கத்தில் வைத்திருங்கள், கடவுச்சொல்லை விட விசை அல்லது முகவருக்கு முன்னுரிமை தாருங்கள். பின்னர் பார்வையாளர் பயன்படுத்தும் சரியான URL-ஐச் சோதியுங்கள், ஏனெனில் செயல்படும் SSH அமர்வும் செயல்படும் திரை இணைப்பும் இரண்டு வெவ்வேறு முடிவுகள்.

macOS-இன் அசல் வாடிக்கையாளருக்கு, பார்வையாளரை உள்ளூர் URL மூலம் அடையலாம்: open "vnc://127.0.0.1:15900". சாளரம் திறந்து தொலை புரவலன் அங்கீகாரத்தை நிராகரித்தால், சுரங்கப்பாதை சரியானது, பிரச்சினை இலக்கில் உள்ளது. சாளரம் ஒருபோதும் திறக்கவில்லை எனில், பிரச்சினை கேட்பானில் அல்லது போர்ட்டில் உள்ளது.

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