WireGuard சுரங்கப்பாதைக்கு வெளியே ஒரு Linux செயல்முறையை இயக்குவது எப்படி
ஒரு நிரலுக்கு அதன் சொந்த பிணைய சூழலைக் கொடுங்கள், அது முழு சுரங்கப்பாதை கொண்ட WireGuard புரவலனை விட்டு வெளியேறும், பின்னர் அதைத் தடுக்கும் அனுப்புதல் மற்றும் குறியிடும் விதிகளைச் சரிசெய்யவும்.
வழிகளைத் திருத்துவதன் மூலம் ஒரு நிரலை முழு சுரங்கப்பாதை கொண்ட WireGuard புரவலனிலிருந்து விலக்க முடியாது. வழிகள் இலக்கின் அடிப்படையில் பாதையைத் தேர்ந்தெடுக்கின்றன, நீங்கள் விலக்க விரும்புவது ஒரு செயல்முறை, எனவே கர்னலுக்கு ஒப்பிட எதுவும் இல்லை. செயல்படக்கூடிய அணுகுமுறை அந்த செயல்முறைக்கு அதன் சொந்த பிணைய சூழலைக் கொடுப்பதுதான்: அதன் சொந்த இடைமுகம், முகவரிகள் மற்றும் இயல்புநிலை வழியைக் கொண்ட பெயர்வெளி, veth இணை மூலம் புரவலனுடன் இணைக்கப்பட்டது. இதை நான் Ubuntu 24.04 இல் wireguard-tools 1.0.20210914 உடன் இயக்கினேன், பெயர்வெளி ஒருபோதும் சிக்கலாக இல்லை — புரவலனின் அனுப்புதல் கொள்கையும் சுரங்கப்பாதையின் குறியிடும் விதிகளும்தான் சிக்கலாக இருந்தன.
முதலில் உங்களுக்குத் தேவையான சூழல் வகையைத் தேர்ந்தெடுக்கவும்
நடைமுறையில் இரண்டு வடிவங்கள் தோன்றும். புரவலன் முழு சுரங்கப்பாதையை இயக்கி ஒரு நிரல் ISP பாதையில் வெளியேற வேண்டும் என்றால், நீங்கள் இரண்டாவது பெயர்வெளியை உருவாக்கி, அதைப் புரவலனுடன் இணைத்து, அதற்காகப் போக்குவரத்தை அனுப்பவும் மொழிபெயர்க்கவும் புரவலனை அனுமதிக்கிறீர்கள். ஒரு பெயர்வெளி ஏற்கனவே VPN இடைமுகத்தைக் கொண்டிருந்து, அதன் உள்ளே தொடங்கும் கட்டளையை மட்டும் நீங்கள் விரும்பினால், அது வழக்கமான ip netns exec நிலை, மேலும் வழியமைப்பு வேலையின் பெரும்பகுதி ஏற்கனவே முடிந்துவிட்டது.
எந்த வடிவமும் ஒரே செயல்முறை ஐடிக்கு வரம்பிடப்பட்ட விதியை உங்களுக்குத் தராது. Netfilter முகவரிகள், துறைகள், குறிகள் மற்றும் இடைமுகங்களைப் பொருத்துகிறது; ஒவ்வொரு செயல்முறைக்கும் வழியமைப்பு அட்டவணை இல்லை. குறியிடுதல் போக்குவரத்தை வழிநடத்த முடியும், ஆனால் நீங்கள் ஏற்கனவே அடையாளம் கண்ட பாக்கெட்டுகளில் குறி வைக்கப்பட வேண்டும், அது ஒரு அடுக்கு கீழே உள்ள அதே சிக்கல். பெயர்வெளி அந்த செயல்முறை மரத்திற்கான முழு அடுக்கையும் பிரிக்கிறது, எனவே இதுவே வழக்கமான பதில்.
தேவை உண்மையிலேயே சுரங்கப்பாதையிலிருந்து எதுவும் வெளியேறக்கூடாது என்பதாக இருந்தால், அதற்குப் பதிலாகச் சுரங்கப்பாதையை நிறுத்துங்கள். பெயர்வெளி கலப்பு நிலைக்காக உள்ளது: ஒரு நிரல் வெளியே, மற்ற அனைத்தும் உள்ளே, அதே இயந்திரத்தில், அதே நேரத்தில்.
இரண்டாவது சூழலை உருவாக்கி அதைப் புரவலனுடன் இணைக்கவும்
ஒரு எடுத்துக்காட்டு அமைப்பு: புரவலனிடம் இயல்புநிலை வழியைச் சுமக்கும் WireGuard இடைமுகமும்,clearnet எனப்படும் பிணைய பெயர்வெளியும் உள்ளன, அது veth இணை மூலம் புரவலனுடன் இணைக்கப்பட்டுள்ளது. கீழே உள்ள முகவரிகள் எடுத்துக்காட்டுகள்.
ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1
இந்தப் பெயர்வெளி இப்போது புரவலனை அடைய முடியும், வேறு எங்கும் இல்லை. புரவலன் போக்குவரத்தை அனுப்பி மூல முகவரியை மீண்டும் எழுத வேண்டும், ஏனெனில் 192.168.100.0/24 தனிப்பட்டது, மேலும் மேல்நிலை வழியமைப்பான் அதற்குத் திரும்பிச் செல்லும் வழியைக் கொண்டிருக்கவில்லை:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE
மேலும் செல்வதற்கு முன் பெயர்வெளியின் பக்கத்தை உறுதிசெய்யவும்.ip netns exec clearnet ip route veth வழியையும் 192.168.100.1 வழியாக இயல்புநிலை வழியையும் காட்ட வேண்டும், அந்த முகவரிக்கான ping பதிலளிக்க வேண்டும். புரவலனின் முகவரிக்கான ping தோல்வியடைந்தால், முகவரிகள் அல்லது இணைப்பின் நிலை தவறானது, எந்த firewall விதியும் உதவாது.
பெயர்கள் தீர்க்கப்பட்டும் எதுவும் திரும்பி வராதபோது, FORWARD ஐப் படியுங்கள்
வழக்கமான தோல்வி வழியமைப்பு பிழையைப் போலத் தோன்றுகிறது: பெயர்வெளி ஒரு பெயரைத் தீர்க்கிறது, பாக்கெட் வெளியேறுகிறது, எந்தப் பதிலும் ஒருபோதும் வராது. FORWARD கொள்கை DROP ஆக உள்ள புரவலன்களில் — பல விநியோகங்களும் கடினப்படுத்தப்பட்ட பிம்பங்களின் பெரும்பாலானவையும் அப்படிச் செய்கின்றன — பாக்கெட் வழியிலேயே நிராகரிக்கப்படுகிறது, நிரல் அச்சிடும் பிழை வடிகட்டலைப் பற்றி எதுவும் சொல்லாது.
எதையும் சேர்ப்பதற்கு முன் சங்கிலியைப் படியுங்கள்:
iptables -S FORWARD
nft list chain inet filter forward
பின்னர் போக்குவரத்தை இரு திசைகளிலும் அனுமதியுங்கள், எண்ணிகளுடன், விதி எப்போதாவது பொருந்தியதா என்பதை அறிய:
iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'
பூஜ்ஜிய பாக்கெட் எண்ணி கொண்ட விதி பாதையில் இல்லை. ஒன்று இடைமுகப் பெயர்கள் நீங்கள் கருதியதிலிருந்து வேறுபடுகின்றன, அல்லது சங்கிலியில் முந்தைய விதி பாக்கெட்டை முதலில் ஏற்றுக்கொண்டது, நிராகரித்தது அல்லது திருப்பியது. வரிசையைச் சரிசெய்யுங்கள், விதியின் உரையை அல்ல.
பதில் போக்குவரத்து என்பது மக்கள் மறக்கும் பாதி. திரும்பும் விதிக்கு அதே veth பெயர் மற்றும் இணைப்பு நிலைப் பொருத்தம் தேவை, அல்லது கொள்கையைத் திறந்து வைத்தால் எளிய இடைமுக ஏற்பு தேவை. வெளிச் செல்லும் விதியை மட்டும் சேருங்கள், அசல் அறிகுறி திரும்பி வரும், உங்கள் புதிய விதி அங்கே சரியாகத் தோன்றும்.
சுரங்கப்பாதையின் குறியிடும் விதிகளைப் புதிய பாதையிலிருந்து விலக்கி வைக்கவும்
இந்தப் படி ஒரு செயல்படும் பெயர்வெளியைக் கசியும் ஒன்றாக மாற்றுகிறது. WireGuard அமைப்புகள் பொதுவாக firewall குறி கொள்கையைத் தங்கள் சொந்த வழியமைப்பு விதிகள் மற்றும் தனி அட்டவணையுடன் நிறுவுகின்றன, எனவே குறியிடாத பாக்கெட்டுகள் பிரதான அட்டவணைக்குத் திரும்பி விழுகின்றன, குறியிடப்பட்டவை சுரங்கப்பாதை அட்டவணையைப் பயன்படுத்துகின்றன. பெயர்வெளியிலிருந்து அனுப்பப்படும் போக்குவரத்து வெளியேறும்போது கொள்கை வழியமைப்புக்கு எதிராக மதிப்பிடப்படுகிறது, அந்த விதிகள் எவ்வாறு எழுதப்பட்டன என்பதைப் பொறுத்து அது சுரங்கப்பாதை அட்டவணையில் விழலாம்.
இரண்டு சேர்த்தல்கள் பாதைகளைப் பிரிக்கின்றன. பெயர்வெளியின் துணை வலையத்திற்காக mangle சங்கிலியில் முன்கூட்டியே திரும்பி, அந்தத் துணை வலையத்தைப் பிரதான அட்டவணையில் வைக்கும் மூல அடிப்படையிலான விதியைச் சேருங்கள்:
iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100
என் புரவலனில் முன்னுரிமை 100 சுரங்கப்பாதை விதிகளுக்கு முன் வரிசைப்படுத்தப்படுகிறது, எனவே அந்த மூலத்திற்கு சாதாரண அட்டவணை முடிவு செய்கிறது. எண்ணைக் கண்மூடித்தனமாக நகலெடுக்க வேண்டாம்: எந்த முன்னுரிமைகளைwg-quick நிறுவுகிறதோ அவை பதிப்புகளுக்கும் IPv4 மற்றும் IPv6 அமைப்புகளுக்கும் இடையே வேறுபடுகின்றன, எனவே இயக்கவும்ip rule show மேலும் உங்கள் இயந்திரத்தில் சுரங்கப்பாதை விதிகளுக்கு முன் விழும் முன்னுரிமையைத் தேர்ந்தெடுக்கவும்.
விதிப் பட்டியலை நம்புவதற்குப் பதிலாக மூலத்திற்கான தேடலால் சரிபார்க்கவும்:
ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1
முதல் கட்டளை WireGuard இடைமுகத்தைத் தெரிவித்தால், புதிய விதி இன்னும் சுரங்கப்பாதைக் கொள்கைக்கு முன் இல்லை. அது WAN இடைமுகத்தைத் தெரிவித்து, இரண்டாவது இன்னும் veth இயல்புநிலையைக் காட்டினால், புரவலனும் பெயர்வெளியும் உடன்படவில்லை, நீங்கள் இரண்டு வழியமைப்பு அட்டவணைகளையும் மீண்டும் படிக்க வேண்டும்.
இணைப்பைத் திறக்கும் செயல்முறையைத் தொடங்குங்கள்
கட்டளையைத் தொடங்குவது ஒரு வரி, ஆனால் சாக்கெட்டை உண்மையில் உருவாக்கும் செயல்முறையைத் தொடங்குங்கள்.ip netns exec clearnet curl -s https://ifconfig.me மிகச் சிறிய நேர்மையான சோதனை: பெயர்வெளி உலகிற்கு வழங்கும் முகவரியைக் காட்டுகிறது, புரவலன் பயன்படுத்தும் முகவரியை அல்ல.
ஒரு சேவைக்கு, செயல்முறை அதன் முழு வாழ்நாளிலும் அதில் இருக்கும் வகையில் பெயர்வெளியைப் பாதை வழியாக இணைக்கவும்:
[Service]
NetworkNamespacePath=/run/netns/clearnet
வரைகலை பயன்பாடுகள் ஒரு-வரி அணுகுமுறை அமைதியாகத் தோல்வியடையும் இடம். மெனுவிலிருந்து தொடங்கப்படும் உலாவி பெரும்பாலும் கோரிக்கையை ஏற்கனவே பெயர்வெளிக்கு வெளியே இயங்கும் நிகழ்வுக்குக் கொடுத்துவிடும், எனவே புதிய சாளரம் தோன்றுகிறது, போக்குவரத்து இன்னும் சுரங்கப்பாதை வழியாக வெளியேறுகிறது. உண்மையில் புதிய நிகழ்வு உருவாகும் வகையில் அதற்குத் தனி சுயவிவரம் கொடுங்கள், பின்னர் ஊகிப்பதற்குப் பதிலாக செயல்முறையின் சூழலைச் சரிபார்க்கவும்:
readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet
இரண்டு வெளியீடுகளும் பொருந்த வேண்டும். அதே சரிபார்ப்பு எந்த நீண்ட நேரம் இயங்கும் நிரலுக்கும் வேலை செய்கிறது, தொடக்கி நீங்கள் நினைத்ததைச் செய்தது எனக் கருதுவதற்குப் பதிலாக ஒவ்வொரு பயன்பாட்டிற்கும் ஒரு முறை செய்வது மதிப்புள்ளது.
பெயர் தீர்வுக்கு அதன் சொந்த முடிவு தேவை. பெயர்வெளியை உருவாக்குவது அதற்குத் தீர்வி உள்ளமைவைத் தராது; ஒவ்வொரு பெயர்வெளிக்குமான கோப்புகள் இதன் மூலம் ஆதரிக்கப்படுகின்றன /etc/netns/<name>/resolv.conf, அது இல்லாமல் தவறாகப் படிக்க எளிதான நடத்தையைப் பெறுவீர்கள். IPv6 க்கும் அதே அணுகுமுறை தேவை: பெயர்வெளிக்கு v6 இயல்புநிலை வழி இல்லாமல், பயன்பாடு v6 ஐ விரும்பினால், கோரிக்கைகள் பின்வாங்குவதற்கு முன் தேங்கலாம், அது உடைந்த சுரங்கப்பாதை போலத் தோன்றும்.
வெளியேறும் முகவரியை மட்டுமல்ல, சட்டகத்தைச் சரிபார்க்கவும்
செயல்படும் பொது முகவரி வழியை நிரூபிக்கிறது, முழு தேவையை அல்ல. மீதமுள்ளதை இந்த வரிசையில் செல்லுங்கள்:
ip netns exec clearnet ip route get 1.1.1.1veth இயல்புநிலையைக் காட்டுகிறது, WireGuard இடைமுகத்தை அல்ல.- கோரிக்கை இயங்கும்போது இரண்டு விதிகளின் FORWARD எண்ணிகள் அதிகரிக்கின்றன.
- பயன்பாட்டுச் செயல்முறை நீங்கள் எதிர்பார்க்கும் பெயர்வெளி inode ஐத் தெரிவிக்கிறது.
- மறுதொடக்கத்திற்குப் பிறகு சேவை தொடங்குவதற்கு முன் பெயர்வெளி உள்ளது; முன்னதாக இயங்கும் unit தோல்வியடைகிறது, அல்லது மோசமானது, பெயர்வெளிக்கு வெளியே இயங்குகிறது.
பின்னர் சுரங்கப்பாதை விழும்போது என்ன நடக்க வேண்டும் என்பதைத் தீர்மானியுங்கள். பெயர்வெளி தொடர்ந்து செயல்படுகிறது, அதுவே இந்தப் பயிற்சியின் நோக்கமும் அதே சமயம் ஆபத்தும்: விலக்கப்பட்ட நிரல் இணைக்கப்பட்டே இருக்கும், மற்ற அனைத்தும் நிற்கும். இதைக் கொள்கைத் தேர்வாகப் பதிவு செய்து, விலக்கு எதை உள்ளடக்கவில்லை என்பதைத் தெளிவுபடுத்துங்கள் — கணக்கு அடையாளம், சேமிக்கப்பட்ட உலாவி நிலை மற்றும் உங்கள் DNS வழங்குநர் அனைத்தும் பிணைய பெயர்வெளியின் எல்லைக்கு வெளியே உள்ளன, விலக்கை அநாமதேயமாகக் கருதுவதே உள்ளமைவை விட நீடிக்கும் தவறு.