VPN நுழைவாயில் மறுதொடக்கம் செய்யப்பட்ட பிறகும் IPv4 அனுப்புதல் நிலைத்திருக்கச் செய்யுங்கள்

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

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

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

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

பொதிகள் உண்மையில் இருக்கும் இடத்திலேயே மதிப்பைப் படியுங்கள்

ஓம்புநர் பெயர்வெளியில் வழிநடத்தும் நுழைவாயிலில், ஒரு கட்டளை கேள்விக்குப் பதிலளிக்கிறது: sysctl net.ipv4.ip_forward. உள்வழி மற்றும் அடுத்த பாதை பெயரிடப்பட்ட பெயர்வெளியில் வாழும்போது, அந்தப் பெயர்வெளியிடம் கேளுங்கள்: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. ஓம்புநரின் மதிப்பு பெயர்வெளியின் மதிப்புக்கு மாற்றல்ல, ஓம்புநரில் ஒன்று இருப்பது எதற்கும் சான்று அல்ல.

ஒவ்வொரு வழிநடத்தல் சூழலுக்கும் ip netns க்கு கொடுக்கக்கூடிய லேபிள் இருக்காது. கொள்கலன் இயக்கச் சூழல்களும் சேவைகளும் நட்பான பெயரில் ஒருபோதும் பதிவு செய்யப்படாத பெயர்வெளிகளை உருவாக்குகின்றன, அவற்றுக்கு இயக்கச் சூழலின் ஆய்வுக் கருவிகளைப் பயன்படுத்துகிறீர்கள். vpn-gw க்குப் பதிலாக உண்மையான பெயரையோ அதே சூழலை அடையும் இயக்கச் சூழல் முறையையோ இடுங்கள், ஓம்புநர் மட்டத்தில் ஊகிப்பதை நிறுத்துங்கள்.

அமைப்புக்கு ஒரே உரிமையாளரைக் கொடுங்கள்

வழக்கமான systemd ஓம்புநர் நுழைவாயிலில், நிலையான வடிவம் நிர்வாகி தேர்ந்தெடுத்த பெயருள்ள drop-in கோப்பு, எடுத்துக்காட்டாக /etc/sysctl.d/60-vpn-forwarding.conf, அதில் net.ipv4.ip_forward = 1 உள்ளது. கோப்பை எழுதுங்கள், பின்னர் நேரடி நிலையும் மாறும் வகையில் அதே குறிப்பிட்ட கோப்பை ஏற்றுங்கள்: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, அதன் பிறகு மீண்டும் படித்துச் சரிபாருங்கள். கோப்பின் பெயர் ஒரு எடுத்துக்காட்டு, ஒதுக்கப்பட்ட VPN பாதை அல்ல, முன்னிலை எண் முக்கியம் ஏனெனில் பின்னர் வரிசைப்படுத்தப்படும் கோப்புகள் வெல்லும்.

முன்னுரிமை என்பது நிலைத்தன்மை அமைதியாக உடையும் இடம். விநியோகத்தின் ஏற்றியையும் உங்கள் சொந்த drop-in ஐயும் சரிபாருங்கள், ஏனெனில் procps sysctl --system இறுதியில் /etc/sysctl.conf ஐயும் படிக்கிறது, ஆனால் systemd இன் sysctl.d வரிசை முற்றிலும் வேறு வரிசையாகும். பின்னர் செய்யும் ஒதுக்கீடு அதே விசையை உடனே திரும்ப வைக்கலாம், உங்கள் கோப்பு சரியாகவும் பயனுள்ள மதிப்பு தவறாகவும் இருக்கும். அந்த வாதத்தை வெல்ல ஏற்கனவே உள்ள நிர்வாகக் கோப்பை மேலெழுத வேண்டாம்; உரிமையாளரைக் கண்டுபிடித்து அங்கேயே மாற்றுங்கள்.

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

சுவிட்சைத் திருப்புவதற்கு முன் அதன் விலையை அறியுங்கள்

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

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

நிலைத்தன்மையை நிரூபியுங்கள், பின்னர் பாதையின் மீதியைச் சோதியுங்கள்

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

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

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