VPN சகன் மற்ற இடைமுகங்களுக்கு பிங் செய்வது அவை உள்ளூர் என்பதால்

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

ஒரு பாதை மற்றொருவருக்காக பாக்கெட்டுகளை மாற்றுகிறது; மற்றொன்று அவற்றைப் புரவலனுக்கே வழங்குகிறது.

புரவலனுக்கு முகவரியிடப்பட்ட பாக்கெட் புரவலனிலேயே தங்குகிறது

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

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

ip_forward ஏன் பொருந்தாது

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

அதனால்தான் மாற்றலை முடக்கி புரவலன் தனிமைப்படுத்தப்பட்டது எனக் கருதுவது பாதுகாப்பின் பொய்யான உணர்வை உருவாக்குகிறது.

முடிவெடுத்த உள்ளூர் அட்டவணையைப் படியுங்கள்

ip rule show பொதுவாக பூஜ்ஜிய முன்னுரிமை விதியைத் தெரிவிக்கிறது, அது அனைத்து தேடல்களையும் முதலில் உள்ளூர் அட்டவணைக்கு அனுப்புகிறது, ip route show table local புரவலனின் சொந்த முகவரிகளை உள்ளூர் எல்லையுடன் பட்டியலிடுகிறது. அந்த அட்டவணையில் நிர்வாகரீதியாக முடக்கப்பட்ட ஆனால் இன்னும் கட்டமைக்கப்பட்ட இடைமுகங்களின் முகவரிகளும் அடங்கும். நிலையாக ஒதுக்கப்பட்ட IPv4 முகவரிகள் பொதுவாக இணைப்பு துண்டிக்கப்பட்ட பிறகும் நீடிக்கும், அதனால்தான் முடக்கப்பட்ட பாலத்திற்கு பிங் இன்னும் வெற்றிபெற்று இயக்குபவரை ஆச்சரியப்படுத்தலாம்.

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

ஒரு சகன் உண்மையில் எங்கு வரை செல்கிறது

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

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

நீங்கள் ஓய்வு பெறச் செய்ய நினைத்த முகவரிகளையும் சரிபார்க்கவும். ஒரு இடைமுகத்திலிருந்து முகவரியை நீக்குவது பழைய முகவரியின் மீது ஃபயர்வால் விதிகளை அடுக்குவதை விட நம்பகமானது.