NEW மட்டுமான ஃபயர்வால் விதிகள் ஒவ்வொரு WAN பாதையையும் மூடுவதில்லை

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

நிலை என்பது பொருத்த நிபந்தனை, தீர்ப்பு அல்ல

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

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

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

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

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

எண்ணிகள் எந்த விதி உண்மையில் பொருந்தியது என்பதைக் கூறுகின்றன, அவை பொதுவாக முடிவுக்குப் பின் எடுக்கப்பட்ட பாக்கெட் பதிவை விட அதிக தகவல் தருகின்றன. பூஜ்ஜிய எண்ணி உள்ள விதியை அடையவில்லை, அதன் நிலை எதைக் குறிப்பிட்டாலும்.

தடையை நிலையிலிருந்து சுயாதீனமாக வெளிப்படுத்துங்கள்

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

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

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

குழுவில் உண்மையில் யார் இருக்கிறார்கள் என்பதைச் சரிபார்க்கவும்

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

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

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

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