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

விதி உண்மையில் எதைப் பொருத்துகிறது

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

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

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

ஹுக் விதி யாருக்குப் பொருந்தும் என்பதைத் தீர்மானிக்கிறது

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

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

HookTraffic it seesRight for this policy
inputAddressed to the gatewayNo, that is the host's own services
forwardRouted through the gatewayYes, for client-to-destination traffic
outputGenerated by the gatewayNo, that is the opposite direction

இணைப்பைப் படிப்பது ஒரு வரிச் சரிபார்ப்பு, இது பாக்கெட்டை ஒருபோதும் பார்க்காத சங்கிலியில் விதி விழுவதைத் தடுக்கிறது.

பரந்த accept க்கு முன் விதியை வைக்கவும்

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

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

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

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

ஏற்கனவே உள்ள ஓட்டங்கள் உங்கள் புதிய விதியைக் கவனிக்காது

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

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

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

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

இந்த விதி எதுவல்ல

இந்த விதி களப் பட்டியல், IPv6 கொள்கை அல்லது ஒரு தனி பயன்பாட்டுக் கணக்கின் மீதான கட்டுப்பாடு அல்ல.

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

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

தொடர்புடைய கட்டுரைகள்