UID விதிகளுடன் ஒரு Linux செயலியை VPN உடன் இணைப்பது

Linux இல் ஒரு நிரலை VPN உடன் இணைப்பது முக்கியமாக வழித்தடப் பிரச்சனை, மேலும் firewall விதி வழி தேர்ந்தெடுக்கப்பட்ட பிறகு என்ன நடக்கிறது என்பதை மட்டுமே தீர்மானிக்கிறது. சுரங்கம் இயல்புநிலை வழியைப் பெறும் முன்பே நீங்கள் OUTPUT இல் நிரலின் UID ஐப் பொருத்தினால், விதி நீங்கள் பாதுகாக்க விரும்பிய அதே போக்குவரத்தைத் தூக்கி எறிகிறது. அதே விதி நிரலின் DNS வினவல்களுக்குப் பதிலளிக்கும் resolver செயல்முறையையும் பார்க்கவில்லை. வரிசையைச் சரிசெய்யுங்கள், சிறப்புரிமை இல்லாத ஒரு கணக்கு நம்பகமான பிரிக்கப்பட்ட சுரங்கத் தேர்வாக மாறும்.

தீர்ப்புக்கு முன் கணக்கிற்கு வழி கொடுங்கள்

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

கணக்கை முதலில் அதன் சொந்த அட்டவணை வழியாக அனுப்பி, பின்னர் firewall முடிவை உறுதிப்படுத்தட்டும். இது iproute2 uidrange ஐப் புரிந்துகொள்ளும் ஹோஸ்ட்டில் வேலை செய்கிறது, அதை ip rule help ஒரு வரியில் தெரிவிக்கிறது. அட்டவணை 100 சுரங்கம் வழியாக இயல்புநிலை வழியை வைத்திருக்கிறது, விதி UID 1000 ஐ மட்டும் அந்த அட்டவணைக்கு அனுப்புகிறது. மற்ற அனைத்தும் முதன்மை அட்டவணையிலேயே இருக்கும், இயற்பியல் இணைப்பைத் தொடர்ந்து பயன்படுத்தும்.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

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

loopback விலக்கு சுரங்கத்தை ஏன் கொல்கிறது

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

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

loopback இன்னும் DROP க்கு மேலே அதன் சொந்த ACCEPT க்குத் தகுதியானது, ஏனெனில் நிரலின் முதல் DNS பாக்கெட் lo வழியாக உள்ளூர் stub க்குச் செல்கிறது. இரண்டு விதிகளையும் இந்த வரிசையில் வையுங்கள், கணக்கு stub ஐ அடையும், பின்னர் சுரங்கத்தை, வேறு எங்கும் அல்ல.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 தனி விதித் தொகுப்பு, v4 க்கு மட்டுமான இணை ip6tables ஐத் தொடாமல் விடுகிறது. AAAA பதிவுகளை விரும்பும் நிரல் அப்போது DROP ஐ ஒருபோதும் அடையாமல் இயற்பியல் இணைப்பு வழியாக வெளியேறும். இரண்டு விதிகளையும் ip6tables இல் பிரதிபலிக்கவும், அல்லது சுரங்கம் v6 முகவரியை எதுவும் கொண்டு செல்லாதபோது ஹோஸ்ட்டில் IPv6 ஐ முடக்கவும். கையால் சேர்க்கப்பட்ட விதிகளும் மீள்தொடக்கத்தில் மறைந்துவிடும், எனவே அவற்றை netfilter-persistent save மூலம் சேமிக்கவும் அல்லது அதே தர்க்கத்தை துவக்க அலகு ஏற்றும் nftables அட்டவணையாக மீண்டும் உருவாக்கவும்.

DNS பதில்கள் வேறு செயல்முறையிலிருந்து வருகின்றன

நிரலின் 127.0.0.53 க்கான வினவல் loopback ACCEPT ஐக் கடக்கிறது, அங்கேயே UID பொருத்தம் நிற்கிறது. stub resolver அதன் சொந்த சேவைக் கணக்கிலிருந்து மேல்நோக்கி அனுப்புகிறது, எனவே vpnapp உடன் இணைக்கப்பட்ட விதி இரண்டாவது வினவலை ஒருபோதும் பார்க்காது. resolver இணைப்பிற்கு LAN சேவையகத்தைத் தேர்ந்தெடுத்தால், பதில்கள் இயற்பியல் NIC வழியாகத் திரும்பி வரும், நிரலின் சொந்த பாக்கெட்டுகள் சுரங்கத்திலேயே இருக்கும். தெரியும் முடிவு உடைந்த பெயர்களுடன் செயல்படும் சுரங்கம், அல்லது நீங்கள் தேர்ந்தெடுக்காத சேவையகம் பதிலளிக்கும் பெயர்கள்.

பெயர் தீர்வை நிரலில் அல்ல, சுரங்க இணைப்பில் சரிசெய்யுங்கள். சுரங்க சுயவிவரத்திற்கு DNS சேவையகம் மற்றும் வழித்தடக் களத்தைக் கொடுத்து, பின்னர் resolvectl query மற்றும் resolvectl status tun0 மூலம் முக்கியமான பெயர்களுக்கு resolver அதைப் பயன்படுத்துவதை உறுதிப்படுத்துங்கள். பிணையப் பெயர் இடத்திற்குள் பிரச்சனை மறைந்துவிடும், ஏனெனில் இடத்தின் resolver சுரங்கத்தை மட்டுமே அறியும்.

கணக்கிலிருந்தே விதியைச் சரிபார்க்கவும்

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

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

எண்ணிகள் ஒரு விதி எப்போதாவது இயங்கியதா என்பதைக் காட்டுகின்றன. iptables -vnL OUTPUT இயக்கி, ஒவ்வொரு விதிக்கும் அருகிலுள்ள பாக்கெட் எண்ணிக்கையைப் படித்து, உண்மையான போக்குவரத்திற்குப் பிறகு DROP அருகிலுள்ள பூஜ்ஜியத்தைப் பொருத்தத் தவறாகக் கருதுங்கள்.

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