ஒரு IPv4 இலக்கை OpenVPN சுரங்கப்பாதையின் வெளியே அனுப்புவது எப்படி

பெரும்பாலான முழு சுரங்கப்பாதை அமைப்புகள் ஒவ்வொரு தொகுப்பையும் VPN வழியாக அனுப்புகின்றன, மேலும் redirect-gateway அதை சாத்தியமாக்கும் கட்டளை. ஒரு தனி இலக்கை இன்னும் விலக்கலாம். அந்த முகவரிக்கு net_gateway இடம்வைப்பானுடன் ஒரு புரவலன் பாதையைச் சேர்த்தால், இயந்திரத்தின் அசல் நுழைவாயில் வழியாக அதை அடைய வாடிக்கையாளருக்குச் சொல்லப்படுகிறது, மற்ற அனைத்தும் சுரங்கப்பாதையைத் தொடர்ந்து பயன்படுத்துகின்றன.

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

net_gateway உண்மையில் எதைக் குறிக்கிறது

அந்த விலக்கிற்கான சுயவிவரப் பதிவு ஒரு வரி: route 198.51.100.77 255.255.255.255 net_gateway. முதல் முகவரி இலக்கிற்கான ஆவண இடம்வைப்பான், முகமூடி அதை ஒரு புரவலன் பாதையாக மாற்றுகிறது, கடைசி டோக்கன் நுழைவாயில் இடம்வைப்பானைக் குறிக்கிறது. OpenVPN பாதைகளை நிறுவும்போது நுழைவாயில் இடம்வைப்பான்களைத் தீர்க்கிறது. vpn_gateway என்பது சுரங்கப்பாதையின் சொந்த நுழைவாயில், அதாவது VPN இணைப்பின் தொலைப் பக்கம். net_gateway என்பது VPN எதையும் மாற்றுவதற்கு முன் புரவலனிடம் இருந்த இயல்புநிலை நுழைவாயில், இது பொதுவாக இயற்பியல் பிணையத்தின் உள்ளூர் திசைவி.

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

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

புரவலன் பாதை சுரங்கப்பாதையின் இயல்புநிலையை ஏன் வெல்கிறது

வழித்தடம் மிகக் குறிப்பிட்ட பொருந்தும் முன்னொட்டால் தீர்மானிக்கப்படுகிறது. redirect-gateway def1 பொதுவாக இயல்புநிலைப் பாதையை மாற்றாது; அது இரண்டு பாதிகளைச் சேர்க்கிறது, முகவரி இடத்தின் கீழ்ப் பாதிக்கு ஒரு பாதை மற்றும் மேற்பாதிக்கு ஒன்று, அதனால் அசல் இயல்புநிலைப் பாதை மற்ற பயன்பாடுகளுக்கு பாதுகாக்கப்படுகிறது. அந்த பாதிகள் ஒரு முகவரியை விட அகலமானவை.

255.255.255.255 முகமூடியுடன் ஒரு முகவரிக்கான பாதை /32, இது IPv4 க்கு சாத்தியமான அதிகபட்ச குறிப்பிட்டத்தன்மை. அந்த முகவரிக்கான தொகுப்பு மதிப்பிடப்படும்போது /32 பொருந்தி, எந்தப் பாதை முதலில் நிறுவப்பட்டது என்பதைப் பொருட்படுத்தாமல் வெல்கிறது. இதுவே விலக்கின் பின்னணி முறை, பாதை உண்மையில் இருந்தால் Linux, macOS மற்றும் Windows இல் இது ஒரே மாதிரி வேலை செய்கிறது.

Windows இரண்டாவது பரிமாணத்தைச் சேர்க்கிறது. இரண்டு பாதைகள் சமமாக குறிப்பிட்டதாக இருந்தால், குறைந்த மெட்ரிக் உள்ளது வெல்கிறது, VPN அடாப்டர் முடிவை மாற்றும் இடைமுக மெட்ரிக்கைக் கொண்டிருக்கலாம். /32 இன்னும் பாதிகளை விட குறிப்பிட்டது, எனவே விலக்கு பொதுவாக நிலைத்திருக்கும், ஆனால் முந்தைய அமர்வின் பழைய பாதை சமமாக குறிப்பிட்டதாக இருந்தால் குழப்பமான முடிவைத் தரலாம்.

விலக்கு எதை உள்ளடக்கவில்லை

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

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

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

உங்களை நீங்கள் ஏமாற்றாமல் விலக்கைச் சரிபார்த்தல்

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

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

இறுதியாக, பாதையை மேலெழுதலாம் என்பதைக் கட்டுப்பாட்டுகளைச் சரிபார்க்கவும். வாடிக்கையாளர் பக்க kill switch அல்லது Windows இன் block-outside-dns அமைப்பு நேரடி போக்குவரத்தைத் தடை செய்யலாம், இது பாதை சரியாக இருந்தாலும் தோல்வியடையும் இணைப்பாகத் தோன்றுகிறது. விலக்கு வேலை செய்வது போல் தோன்ற அந்தக் கட்டுப்பாட்டுகளை முடக்க வேண்டாம்; கொள்கை நேரடிப் பாதையைத் தடை செய்தால், விலக்கு VPN சேவை உரிமையாளருக்கான வடிவமைப்புப் பிரச்சினை.

மீண்டும் இணைந்த அல்லது பிணையம் மாறிய பிறகு மீண்டும் சரிபார்க்கவும், ஏனெனில் VPN க்கு முந்தைய நுழைவாயிலும் கிடைக்கும் பாதையும் சுயவிவரத்தின் அல்ல, அந்தக் கணத்தின் பண்புகள்.