SSH வழியாக VPN கிளையண்ட்டைத் தொடங்குகிறீர்களா? முதலில் உங்கள் சொந்த வழியைப் பின் செய்யுங்கள்
முழு டன்னல் கிளையண்ட் உங்கள் SSH பதிலைச் சுமக்கும் அட்டவணையை மீண்டும் எழுதுகிறது. பழைய கேட்வே வழியாக ஒரு ஹோஸ்ட் வழியைப் பின் செய்யுங்கள், அல்லது கிளையண்ட்டை அதன் சொந்த பெயர்வெளியில் இயக்குங்கள்.
நீங்கள் SSH வழியாக ஒரு கட்டுமான ஹோஸ்ட்டுக்குள் சென்று, அதில் VPN கிளையண்ட்டைத் தொடங்குகிறீர்கள், அமர்வு பதிலளிப்பதை நிறுத்துகிறது. எதுவும் செயலிழக்கவில்லை, வெளிப்படையான அர்த்தத்தில் எதுவும் தவறாக உள்ளமைக்கப்பட்டதாகத் தெரியவில்லை. கிளையண்ட் ஒரு இயல்புநிலை வழியை நிறுவியது, எனவே உங்கள் பணிநிலையத்திற்கான பதில்கள் இப்போது டன்னல் வழியாக வெளியேறுகின்றன, அங்கு உங்கள் பணிநிலையத்தின் முகவரி வழியமைக்க முடியாதது. சுவாரஸ்யமான அம்சம் என்னவென்றால் இந்த முடிவு முன்கூட்டியே ஊகிக்கக்கூடியதாக இருந்தது, மேலும் தீர்வு என்பது கிளையண்ட் தொடங்குவதற்கு முன் எழுதப்படும் ஒரு வழியாகும். ஒரு பிணைய அட்டையுடன் ஒரு சேவையகம், 192.0.2.254 இன் கேட்வே, மற்றும் 203.0.113.9 இலிருந்து இணைக்கும் நிர்வாகி என்று வைத்துக்கொள்வோம்.
தொடங்குவதற்கு முன் பாதையைப் பதிவு செய்யுங்கள்
ip route show default தற்போதைய கேட்வே மற்றும் இடைமுகத்தைப் பெயரிடுகிறது, அதேசமயம் ip route get 203.0.113.9 உங்கள் அமர்வுக்கு கர்னல் எந்த இடைமுகத்தையும் மூல முகவரியையும் பயன்படுத்தும் என்பதைக் காட்டுகிறது. இரண்டு வெளியீடுகளையும் வைத்திருங்கள். டன்னல் மேலே வந்தபிறகும் அந்த இரண்டு கட்டளைகள் இயற்பியல் பாதையை விவரிக்க வேண்டும், அவை அதற்குப் பதிலாக டன்னலை விவரித்தால், அமர்வு ஏற்கனவே கடன் வாங்கிய நேரத்தில் வாழ்கிறது.
முக்கியமானது ஏற்கனவே நிறுவப்பட்ட இணைப்பு, எனவே புதிய உள்நுழைவைக் கொண்டு மட்டும் சரிபார்க்க வேண்டாம். புதிய அமர்வு பழையதிடம் இனி இல்லாத நிலையின் மூலம் சிறிது நேரம் வெற்றிபெறக்கூடும்.
முகவரியை கிளையண்ட்டின் சொந்த உள்ளமைவில் பின் செய்யுங்கள்
கையால் சேர்க்கப்பட்ட வழி மறுதொடக்கத்தில் மறைந்துவிடும் மற்றும் கிளையண்ட்டின் சொந்த அட்டவணை புதுப்பிப்புகளுடன் போட்டியிடுகிறது, எனவே விதிவிலக்கை அட்டவணை நிர்வகிக்கப்படும் இடத்தில் வையுங்கள். OpenVPN இல் net_gateway முக்கியச்சொல் டன்னலுக்கு முன் இருந்த கேட்வேயில் தீர்க்கப்படுகிறது, எனவே route 203.0.113.9 255.255.255.255 net_gateway அதற்கு வெளியே சரியாக ஒரு முகவரியை வைத்திருக்கிறது. WireGuard க்கு வேறு அணுகுமுறை தேவை, ஏனெனில் wg-quick வழிகளைத் தானே நிர்வகிக்கிறது: Table = off அமைத்து PostUp இல் விதிவிலக்கைச் சேர்க்கவும், அதை அகற்றும் பொருந்தும் PostDown உடன். இரண்டு வடிவங்களும் ஒரே நோக்கத்தை வெளிப்படுத்துகின்றன, இரண்டும் விதிவிலக்கை எல்லாவற்றிற்கும் டன்னலை பலவீனப்படுத்துவதற்குப் பதிலாக ஒரு முகவரிக்கு மட்டுப்படுத்துகின்றன.
IPv6 க்கு அதே கருத்து ஒற்றை-ஹோஸ்ட் முன்னொட்டை எடுக்கிறது, மேலும் சுற்றப்பட்ட போக்குவரத்து நிலைமை நினைவில் கொள்ளத்தக்கது: டன்னலின் சொந்த வெளி இணைப்பு நிலையான முகவரியில் இருந்தால், அந்த முகவரி அது சுமக்கும் டன்னலுக்கு வெளியே இருக்க வேண்டும், இல்லையெனில் கிளையண்ட் தன் போக்குவரத்தைத் தனக்குள்ளேயே வழியமைக்கிறது.
அல்லது பிரதான அட்டவணையை சமன்பாட்டிலிருந்து வெளியேற்றுங்கள்
ஹோஸ்ட்டில் பல சேவைகள் தங்கள் இயல்பான பாதையைத் தக்கவைக்க வேண்டியிருக்கும்போது, பிரதான அட்டவணையைத் திருத்துவதை நிறுத்தி கிளையண்ட்டுக்கு அதன் சொந்தத்தைக் கொடுங்கள். veth இணையுடன் கூடிய பிணைய பெயர்வெளி இதை தூய்மையாகச் செய்கிறது: கிளையண்ட்டின் இயல்புநிலை வழி வேறு ஸ்டாக்கில் வாழ்கிறது, அதன் உள்ளே தொடங்கப்பட்ட செயல்முறைகள் மட்டுமே டன்னலைப் பயன்படுத்துகின்றன. கொள்கை வழியமைப்பு ஒரு இலக்கிற்கு இதே போன்ற இடத்தை அடைகிறது, பொருந்தும் போக்குவரத்தை இயல்புநிலை இன்னும் இயற்பியல் கேட்வேயை நோக்கிக் காட்டும் தனி அட்டவணைக்கு அனுப்புவதன் மூலம். எந்த அணுகுமுறையும் ஹோஸ்ட்டின் பிரதான அட்டவணையை புதிய இயல்புநிலை வழி இல்லாமல் விடுகிறது, அந்தப் பண்பே SSH பதிலளிப்பதாக வைத்திருக்கிறது.
இரண்டும் ஒரு ஹோஸ்ட் வழியை விட அதிக இயந்திரம், யந்திரத்தில் ஒன்றுக்கு மேற்பட்ட விஷயங்கள் டன்னலைத் தாண்டி வாழ வேண்டியிருக்கும்போது இரண்டும் மதிப்புள்ளவை.
பின் செய்வது தோல்வியடையக்கூடும் என்று கருதுங்கள்
உங்கள் தற்போதைய பொது முகவரியுடன் பிணைக்கப்பட்ட வழி, உங்கள் வழங்குநர் அதை மீண்டும் ஒதுக்கும் தருணத்தில் உடைகிறது. அப்போது தொலை சேவையகத்திற்கு அந்த முகவரியைச் சார்ந்திராத பாதை தேவை: ஒரு பணியகம், இரண்டாவது நிர்வாக இடைமுகம், அல்லது டன்னலுக்கு வெளியே இருக்கும் தாண்டல் ஹோஸ்ட்.
இரண்டு பாதுகாப்பு நடவடிக்கைகளுக்கு பத்து நிமிடங்கள் ஆகும். சில நிமிடங்களில் உறுதிப்படுத்தல் உள்நுழைவு தோன்றவில்லை என்றால் கிளையண்ட்டை நிறுத்தும் காவலர் பூட்டுதலை தாமதமாக மாற்றுகிறது, மேலும் மாற்றத்தின் போது திறந்து வைக்கப்படும் இரண்டாவது SSH அமர்வு டன்னல் மேலே இருக்கும்போது விதிவிலக்கு செயல்படுவதை நிரூபிக்கிறது. keepalive மட்டும் இங்கு உதவாது, ஏனெனில் பாதை செயலற்றதாக இல்லாமல் போய்விட்டது; அவை மரணத்தைக் கவனிப்பதை எளிதாக்குகின்றன.
முக்கியமான வரிசையில் சரிபார்க்கவும்
டன்னலை இணைக்கவும், உங்கள் முகவரிக்கான வழி இன்னும் இயற்பியல் கேட்வே வழியாக வெளியேறுகிறது என்பதை உறுதிப்படுத்தவும், பின்னர் புதிய அமர்வைத் திறக்கவும். புதிய அமர்வு வேலை செய்து பழையது இருந்தபோதிலும் இறந்தால், காரணம் வழியமைப்பு அல்ல, இணைப்பு கண்காணிப்பு அல்லது நிலை கொண்ட ஃபயர்வால், அது வேறு தீர்வு.
பின் செய்யப்பட்ட முகவரியையும் அதை நிரூபித்த கட்டளையையும் மாற்றப் பதிவில் எழுதுங்கள். அந்த ஹோஸ்ட்டில் அடுத்த முறை கிளையண்ட்டைத் தொடங்கும் நபருக்கு இரண்டும் தேவைப்படும், அதற்குள் முகவரி மாறியிருக்கலாம்.