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

லேப்டாப்பில் அல்ல, ரவுட்டரில் தொடங்குங்கள்

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

எதையும் மாற்றும் முன் காகிதத்தில் மூன்று உண்மைகளை எழுதுங்கள்: WAN இடைமுகத்தின் பெயர், LAN பாலத்தின் பெயர், மற்றும் VPN முனைப்புள்ளியின் முகவரி மற்றும் துறை. மூன்றும் விதிகளில் தேவைப்படும், இடைமுகப் பெயர்களை ஊகிப்பதே சரியாகத் தெரியும் விதித்தொகுப்பு எதுவும் செய்யாததற்கு மிகவும் பொதுவான காரணம்.

ஒரு பாக்கெட் எடுக்கக்கூடிய மூன்று பாதைகளையும் கடந்து செல்லுங்கள்

லேப்டாப்பிலிருந்து இணையத்திற்கான போக்குவரத்து அனுப்பப்படுகிறது, எனவே அது FORWARD சங்கிலியைக் கடக்கிறது. ரவுட்டர் தானே உருவாக்கும் போக்குவரத்து, எடுத்துக்காட்டாக DNS அனுப்புதல், NTP வினவல்கள், DDNS புதுப்பிப்புகள் மற்றும் VPN-இன் கட்டுப்பாட்டு சேனல், OUTPUT வழியாகச் செல்கிறது. ரவுட்டரை நோக்கிய நிர்வாகப் போக்குவரத்து INPUT வழியாக வருகிறது.

எனவே FORWARD-இல் மட்டும் கட்டப்பட்ட கில் சுவிட்ச் வாடிக்கையாளர்களைப் பாதுகாக்கிறது, வேறு எதையும் அல்ல. தொடக்கக் காட்சியின் கசிவு ஏன் மர்மமல்ல, முன்கணிக்கக்கூடியது என்பதை அட்டவணை காட்டுகிறது.

Packet pathExampleChain that sees it
LAN client to WAN or tunnelBrowser requestFORWARD
Router-originatedDDNS update, NTPOUTPUT
Addressed to the routerSSH from the LANINPUT

பெரும்பாலான வடிவமைப்புகளில் INPUT-இல் கில் சுவிட்ச் தேவையில்லை, ஆனால் சுரங்கப்பாதை நிறுத்தப்பட்டிருக்கும் போது நிர்வாக அணுகலை இயங்கவைக்க வேண்டும். இல்லையெனில் VPN முதல் முறை தோல்வியடையும் போது கன்சோல் கேபிளுடன் அலுவலகத்திற்குச் செல்வீர்கள்.

சுரங்கப்பாதை இன்னும் எழக்கூடியபடி விதிகளை வரிசைப்படுத்துங்கள்

வேலை செய்யும் கில் சுவிட்ச் என்பது மறுப்பில் முடியும் அனுமதிப் பட்டியல், அதை கில் சுவிட்சாக ஆக்குவது வரிசையே, செங்கல் அல்ல. முதலில் loopback, VPN முனைப்புள்ளி, நிறுவப்பட்ட ஓட்டங்களுக்கான பதில்கள் மற்றும் சுரங்கப்பாதை இடைமுகத்திற்கு அனுமதி தாருங்கள்; மீதமுள்ளவற்றை இறுதியில் மறுக்கவும்.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

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

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

IPv6-க்கு அதன் சொந்த கதவு தேவை

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

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

இங்கும் வரிசை முக்கியம்: loopback அனுமதி WAN மறுப்புக்கு முன் வர வேண்டும், இல்லையெனில் ரவுட்டரில் உள்ள உள்ளூர் சேவைகள் விநோதமான வழிகளில் தோல்வியடையத் தொடங்கும். நெட்வொர்க் IPv6-ஐ அறவே பயன்படுத்தவில்லை என்றால், அதை WAN மற்றும் LAN-இல் முடக்குவது எளிது, மறக்க எதுவும் மிஞ்சாது.

சில VPN கிளையண்ட்கள் IPv4-க்கு மட்டும் இயல்புநிலை வழியை நிறுவி, இருக்கும் IPv6 இயல்புநிலை வழியைத் தொடாமல் விடுகின்றன. சுரங்கப்பாதை இணைந்த பிறகு ரூட்டிங் அட்டவணையைச் சரிபாருங்கள், கிளையண்ட் கவனித்துக்கொண்டது என்று கருதுவதற்குப் பதிலாக.

சுரங்கப்பாதை நிறுத்தப்பட்ட நிலையில் இதை நிரூபியுங்கள்

ரவுட்டரிலிருந்து சுரங்கப்பாதையை நிறுத்தி மூன்று இடங்களிலிருந்து இந்த வரிசையில் சோதிக்கவும்:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

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

தேவைப்படும் முன் தோல்வி முறையை முடிவு செய்யுங்கள். fail-closed சுரங்கப்பாதை திரும்பும் வரை வாடிக்கையாளர்களை ஆஃப்லைனில் வைத்திருக்கும்; fail-open வழக்கமான WAN அணுகலை மீட்டெடுத்து உங்களுக்கு முக்கியமான போக்குவரத்தின் நோக்கத்தைக் கெடுக்கும். அதிக மெட்ரிக் கொண்ட VPN பூல் நோக்கிய blackhole வழி fail-closed வடிவமைப்புகளுக்கு பயனுள்ள இரண்டாவது அடுக்கு, ஏனெனில் சுரங்கப்பாதை வழி மறையும் போது அது இயல்புநிலைக்குத் திரும்பாமல் தாக்குப்பிடிக்கிறது.

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

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