ஹோஸ்ட் வெளியேறும் VPN இயக்கும்போது உள்ளூர் SSH-ஐ வைத்திருங்கள்
வெளியேறும் சுரங்கப்பாதை உள்ளூர் நிர்வாகத்தை தன்னுடன் எடுத்துச் செல்ல வேண்டியதில்லை. கேட்பானை இணைக்கவும், LAN பாதையை வைத்திருக்கவும், விதியைக் குறைக்கவும், இரு நிலைகளையும் சோதிக்கவும்.
ஒரு சிறிய Linux சேவையகம் தான் வழங்கும் பயன்பாட்டிற்காக வெளியேறும் VPN-ஐ இயக்குகிறது, மேலாளர் இன்னும் அருகிலுள்ள மேசையிலிருந்து SSH மூலம் அதை அடைய விரும்புகிறார். இது நியாயமான தேவை, வழக்கமாக இதற்கு போர்ட் ஃபார்வேர்டிங், வழங்குநர் முகவரி அல்லது சுரங்கப்பாதையில் ஒரு துளை தேவையில்லை. தேவைப்படுவது வேண்டுமென்றே வடிவமைக்கப்பட்ட நிர்வாகப் பாதை, VPN கிளையண்ட் வழிசெலுத்தல் அட்டவணையுடன் செய்ததிலிருந்து மரபுரிமையாக வந்தது அல்ல.
கீழே உள்ள படிகள் மேலாளர் அதே LAN-இல் இருப்பதாகக் கருதுகின்றன.தொலை நிர்வாகம் வேறு பதிலைக் கொண்ட வேறு சிக்கல்.
மேலாளர்கள் பயன்படுத்தும் முகவரிக்கு SSH-ஐ இணைக்கவும்
கேட்பானில் தொடங்கவும்.ss -ltnp | grep :22 sshd எதனுடன் பிணைக்கப்பட்டுள்ளது என்பதைக் காட்டுகிறது, 0.0.0.0-இல் உள்ள கேட்பான் சுரங்கப்பாதை உட்பட ஒவ்வொரு இடைமுகத்திலிருந்தும் இணைப்புகளை ஏற்கிறது. LAN முகவரியில் பிணைப்பது குறுகியது மற்றும் நோக்கத்தைத் தெரியப்படுத்துகிறது:ListenAddress 192.168.10.20 உள்ளேsshd_config, அதைத் தொடர்ந்து கட்டமைப்புச் சோதனை மற்றும் மீள்ஏற்றம். அந்த முகவரியில் ஒரு தட்டச்சுப்பிழை வைல்ட்கார்டை விடத் தெரியும், ஏனெனில் முகவரி இல்லாதபோது sshd தொடங்க மறுக்கிறது.
ஹோஸ்ட் விசைச் சரிபார்ப்பையும் ஒவ்வொரு பயனரின் அங்கீகாரத்தையும் உள்ளபடியே வைத்திருங்கள். “இது உள்ளூர் வலைப்பிண்ணை மட்டுமே” என்பது அங்கீகார முறை அல்ல, பாதை குறுகியது என்பதால் விசைச் சரிபார்ப்பைத் தவிர்க்கும் நிர்வாகச் சேனல் துஷ்பிரயோகத்திற்காகக் காத்திருக்கும் சேனல். DHCP ஒதுக்கீடு அல்லது நிலையான முகவரி இலக்கை ஊகிக்கக்கூடியதாக ஆக்குகிறது, அதை சேவையகத்தின் பொது அடையாளமாக மாற்றாமல்.
LAN பாதையை சுரங்கப்பாதைக்கு வெளியே வைத்திருங்கள்
192.168.10.0/24-இல் முகவரி உள்ள ஹோஸ்ட்டுக்கு அந்த முன்னொட்டுக்கான இணைக்கப்பட்ட பாதை உள்ளது, அதே அட்டவணையில் மிகவும் குறிப்பிட்ட பாதை VPN-இன் இயல்புநிலையை வெல்லும். அதனால்தான் சுரங்கப்பாதை மேலே வரும்போது உள்ளூர் SSH பெரும்பாலும் தானாகவே தொடர்ந்து இயங்குகிறது. ஊகிக்காமல் அதைச் சரிபார்க்கவும்:ip route get 192.168.10.50 கர்னல் பயன்படுத்தும் இடைமுகத்தையும் மூல முகவரியையும் பெயரிடுகிறது, பதில் சுரங்கப்பாதை அல்ல, LAN சாதனமாக இருக்க வேண்டும். மேலாளரின் இயந்திரத்திலிருந்தும் சரிபார்ப்பை மீண்டும் செய்யவும், ஏனெனில் பொதிகள் சேருமா என்பதை அதன் சொந்த அட்டவணையே தீர்மானிக்கிறது. ஒரே கம்பியில் உள்ள இரண்டு ஹோஸ்ட்கள் எந்தத் திசை அடையக்கூடியது என்பதில் உடன்படாமல் இருக்கலாம்.
ஊகம் இரண்டு இடங்களில் உடைகிறது. கொள்கை அடிப்படையிலான வழிசெலுத்தல் விதி, பிரதான அட்டவணையைப் பார்ப்பதற்கு முன் இயல்புநிலை சுரங்கப்பாதையை நோக்கும் அட்டவணைக்கு போக்குவரத்தை அனுப்பலாம். பூட்டு அல்லது kill switch அம்சம் கொண்ட VPN கிளையண்ட் சுரங்கப்பாதைக்குள் நுழையாத போக்குவரத்தையும் தடுக்கலாம், வழிசெலுத்தல் அட்டவணை என்ன சொன்னாலும்.
வழிசெலுத்தப்பட்ட நிர்வாக VLAN-கள் மற்ற வழக்கு. மேலாளர் உள்ளூர் ரவுட்டருக்குப் பின்னால் 192.168.50.0/24-இல் அமர்ந்திருந்தால், சேவையகத்திற்கு அந்த முன்னொட்டுக்கு 192.168.10.1 வழியாக வெளிப்படையான பாதை தேவை, அந்தப் பாதை மீள் இணைப்பைத் தாங்க வேண்டும். விதிவிலக்கை நிர்வாக முன்னொட்டுக்கு மட்டும் குறிப்பிட்டதாக வைத்திருங்கள்; தனிப்பட்ட வரம்புகளுக்கான பரந்த விதிவிலக்கு சுரங்கப்பாதையின் நோக்கத்தைத் தோல்வியடையச் செய்கிறது.
ஃபயர்வால் விதிவிலக்கை விதியைப் போலவே குறுகலாக்கவும்
ஹோஸ்ட் ஃபயர்வாலை இயக்கினால், SSH-ஐ நிர்வாக மூலத்திலிருந்து மட்டும், LAN இடைமுகத்தில் மட்டும் அனுமதிக்கவும். 22 போர்ட்டை எல்லா இடத்திலிருந்தும் அனுமதிக்கும் விதி தேவையை விட பரந்தது, மதிப்பாய்வில் நியாயப்படுத்துவது கடினம். nftables ஹோஸ்ட்டில் விதி இடைமுகமும் மூலமும் பொருந்திய உள்ளீட்டுச் சங்கிலியில் அமைகிறது; iptables ஹோஸ்ட்டில் அதற்கு இணையானது-i மற்றும்-s மீதான இரண்டு பொருத்தங்களின் இணை. விதிக்கு அது சேவை செய்யும் மேலாளர் குழுவைக் குறிப்பிடவும், அடுத்த தணிக்கை 22 போர்ட் ஏன் திறந்திருக்கிறது என ஊகிக்க வேண்டியதில்லை.
VPN கிளையண்டின் சொந்த வடிகட்டியையும் சரிபார்க்கவும். சில கிளையண்ட்கள் வடிவமைப்பின்படி உள்ளூர் போக்குவரத்தை நிராகரிக்கும் விதிகளை நிறுவுகின்றன, கிளையண்ட் அளவிலான நிராகரிப்பின் மேல் சரியான ஃபயர்வால் விதி எதையும் மாற்றாது. ஹோஸ்ட் ஃபயர்வாலைத் திருத்தும் முன் கிளையண்டின் கட்டமைப்பைப் படியுங்கள், ஏனெனில் வரிசையாக இரண்டு வடிகட்டிகள் எதற்கும் ஒத்திருக்காத தோல்வியை உருவாக்குகின்றன.
இரு நிலைகளையும் சோதிக்கவும்
சோதனையை இருமுறை இயக்கவும்: ஒருமுறை சுரங்கப்பாதை இணைக்கப்பட்டிருக்கும்போது, ஒருமுறை துண்டிக்கப்பட்டிருக்கும்போது. ஒவ்வொரு நிலையிலும் கேட்பான், பாதை மற்றும் மேலாளரின் இயந்திரத்திலிருந்து உண்மையான SSH உள்நுழைவை உறுதிப்படுத்தவும். சுரங்கப்பாதை மேலே இருக்கும்போது மட்டும் இயங்கும் பாதை உள்ளூர் நிர்வாகப் பாதை அல்ல; அது ஒரு தற்செயல்.
பின்னர் SSH அமர்வு திறந்திருக்கும்போது சுரங்கப்பாதையை மீண்டும் தொடங்கவும். தாக்குப்பிடிக்கும் அமர்வு வழிசெலுத்தல் நிலையானது என்பதை நிரூபிக்கிறது; வீழும் அமர்வு கிளையண்ட் மீள் இணைப்பில் பாதைகள் அல்லது வடிகட்டிகளை மீண்டும் எழுதுகிறது என்பதைச் சொல்கிறது, அதைச் சம்பவத்திற்கு முன் தெரிந்துகொள்வது நல்லது, சம்பவத்தின்போது அல்ல.
நீங்கள் சோதித்த மூல முகவரியைப் பதிவு செய்யுங்கள், ஏனெனில் 192.168.10.50-க்கு எழுதப்பட்ட விதி மேலாளரின் மடிக்கணினி வேறு துணைப்பிண்ணைக்கு நகர்ந்தால் அமைதியாகத் தோல்வியடைகிறது.
மீட்புப் பாதையை runbook-இல் எழுதுங்கள்
வெளியேறும் VPN உள்ளூர் பாதையை உடைத்தால் என்ன நடக்கும் என்பதை இப்போதே முடிவு செய்யுங்கள். கன்சோல் அணுகல், இரண்டாவது நிர்வாக முகவரி அல்லது கிளையண்டை நிறுத்துவதற்கான ஆவணப்படுத்தப்பட்ட நடைமுறை — அனைத்தும் செல்லுபடியாகும் பதில்கள், அவற்றில் எதுவும் உள்நுழைய வேண்டிய தருணத்தில் சிக்கலைக் கண்டறிவதை விடச் சிறந்தது. சேவையகம் தொலைவில் இருந்தால் உள்ளூர் பாதை இல்லை, சரியான வடிவமைப்பு வெளிப்படையான பொது போர்ட்டுக்குப் பதிலாக தனித்தனியாக அங்கீகரிக்கப்பட்ட தொலை அணுகல் பாதை அல்லது பாஸ்டியன்.
ஆவணத்தில் இரு பாத்திரங்களையும் தனித்தனியாக வைத்திருங்கள்: அருகிலுள்ள மேலாளருக்கான உள்ளூர் SSH, மற்றும் பயன்பாட்டின் போக்குவரத்திற்கான வெளியேறும் சுரங்கப்பாதை. அந்தப் பாத்திரங்கள் எழுதப்பட்டதும், அவற்றில் ஏதேனும் ஒன்றில் எதிர்கால மாற்றத்தைச் சரிபார்க்க தெளிவான இடம் இருக்கும், அடுத்த நபர் VPN உள்ள சேவையகம் இன்னும் தன் LAN முகவரியில் ஏன் பதிலளிக்கிறது என்பதை மீண்டும் கண்டுபிடிக்க வேண்டியதில்லை.