tun0 இல்லையா? nftables இல் மறைகுறியாக்கப்பட்ட IPsec ஐ meta ipsec மூலம் பொருத்துங்கள்

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

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

இரண்டு பொதிகள், ஒரு இடைமுகம்

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

அதை வேறுபடுத்துவது பொதியுடன் இணைக்கப்பட்ட உள்வரும் பாதுகாப்பு பாதையின் சூழல். nftables அதை meta ipsec exists என காட்டுகிறது, பொதி IPsec பாதுகாப்பு பாதை வழியாக வந்தபோது இது உண்மை. அதை வாடிக்கையாளர் குழு, இலக்கு மற்றும் சேவையுடன் இணைக்கவும், விதி பாதுகாப்பாக இருக்கும் அளவுக்கு குறிப்பிட்டதாகிறது.

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

அனுப்பும் விதியை எழுதுங்கள்

10.90.0.0/24 இல் வாடிக்கையாளர்களைக் கொண்ட அங்கீகரிக்கப்பட்ட IPv4 தொலை அணுகல் சேவை மற்றும் 203.0.113.40 இல் ஒரு அங்கீகரிக்கப்பட்ட இலக்கு உள்ளது என வைத்துக்கொள்ளுங்கள். அந்த ஓட்டத்திற்கான விதியின் துண்டு இப்படித் தெரிகிறது.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

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

உள்வரும் சூழல் வெளிச்செல்லும் சூழல் அல்ல

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

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

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

NAT தீச்சுவர் முடிவு அல்ல

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

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

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

சரியான உள் சேவையை சரிபார்க்கவும்

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

nftables குறிப்பு meta ipsec, rt ipsec மற்றும் திசைக்கு உரிய வெளிப்பாடுகளை ஆவணப்படுத்துகிறது, நீங்கள் நிறுவிய பதிப்புடன் தொடரியலைச் சரிபார்க்கும் இடம் அதுதான். மேலும் வரம்பை தெளிவாக வைத்திருங்கள்: இது IPv4 எடுத்துக்காட்டு, இது IPv6 பற்றி எதுவும் சொல்லவில்லை, தன்னிச்சையான பொது துறை அனுப்பலை VPN சேவையின் பகுதியாக்கவில்லை.