net.ipv4.conf.default.forwarding tun0 ஐ ஏன் தொடுவதில்லை

நீங்கள் net.ipv4.conf.default.forwarding=1 அமைத்தீர்கள், VPN ஐ மீண்டும் இயக்கினீர்கள், இருப்பினும் கேட்வே வழிமாற்ற வேண்டிய பொதிகளை சுரங்கப்பாதை இன்னும் வீசுகிறது. கோப்பில் அமைப்பு சரியாகத் தெரிகிறது, இடைமுகம் இன்னும் முன்னனுப்பல் முடக்கப்பட்டுள்ளதாகத் தெரிவிக்கிறது. எதுவும் உடையவில்லை: எதிர்கால இடைமுகங்கள் மரபுரிமையாகப் பெறும் மதிப்பை மாற்றினீர்கள், செயலில் உள்ள சுரங்கப்பாதை பயன்படுத்துவதை அல்ல.

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

மூன்று மதிப்புகளையும் ஒன்றாகப் படியுங்கள்

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

வழக்கமான முடிவு ip_forward = 0, default.forwarding = 1 மற்றும் tun0.forwarding = 0 ஆகும். முதல் இரண்டும் ஹோஸ்ட்டின் பங்கு குறித்து உடன்படவில்லை, மூன்றாவது இடைமுகம் உண்மையில் என்ன செய்கிறது என்பதைக் காட்டுகிறது. இந்தக் கலவை ஒருபோதும் ரவுட்டராக அமைக்கப்படாத, வார்ப்புரு மதிப்பை மட்டும் பெற்ற ஹோஸ்ட்டுடன் பொருந்துகிறது. மூன்று எண்களும் ஒன்றுக்கொன்று முரண்படவில்லை; அவை மூன்று வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. வார்ப்புரு மதிப்பை எழுதுவதும் ஹோஸ்ட்டின் பங்கைத் தீர்மானிக்காது.

ஏன் உலகளாவிய சுவிட்சே நகர்கிறது

net.ipv4.ip_forward கேட்வே முழுவதற்குமான கட்டுப்பாடு. அதை மாற்றுவது அதே செயல்பாட்டின் பகுதியாக ஒவ்வொரு இடைமுகத்தின் முன்னனுப்பல் அமைப்புகளையும் புதுப்பிக்கிறது, அதனால் ஒரு எழுத்தே ஏற்கனவே உள்ள சுரங்கப்பாதையை முன்னனுப்பத் தொடங்கச் செய்யும். default.forwarding பின்னர் துவக்கப்படும் இடைமுகங்களை மட்டுமே விதைக்கிறது, எனவே ஏற்கனவே இருந்த சுரங்கப்பாதை பிறந்த மதிப்பையே தக்கவைக்கிறது.

கர்னல் ஆவணங்கள் ip_forward ஐ தொடர்புடைய காரணத்தால் சிறப்பு என்று குறிக்கின்றன: அதை மாற்றுவது பிற IPv4 அளவுருக்களின் தொகுப்பை ஹோஸ்ட் அல்லது ரவுட்டர் இயல்புநிலைகளுக்கு மீட்டமைக்கிறது. இது அதை ஒரு மழுங்கிய கருவியாக்குகிறது. கேட்வே பங்கை நிறுவுவதன் பகுதியாக ஒருமுறை அமைப்பது நல்லது; பிழைத்திருத்த தந்திரமாக மீண்டும் மீண்டும் மாற்றுவது நீங்கள் நேரம் செலவழித்து சரிசெய்த உள்ளமைவை அமைதியாக மீண்டும் எழுதலாம்.

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

அமைப்பை சரியான இடத்தில் நிரந்தரமாக்குங்கள்

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

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

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

தவறான கருவியால் இதைச் சரிசெய்ய வேண்டாம்

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

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

IPv6 வழக்கைத் தனியாக வையுங்கள்

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

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