உள்ளூர் பயன்பாடு, VPN விதி: உங்கள் FORWARD சங்கிலி ஏன் ஒருபோதும் இயங்காது
இயந்திரத்தில் உள்ள செயல்முறை OUTPUT-ஐப் பயன்படுத்துகிறது, FORWARD அல்ல. சரியான namespace-இல் hook தேர்ந்தெடுத்து, mark அல்லது எளிய route போதுமா எனத் தீர்மானிக்கவும்.
நீங்கள் FORWARD சங்கிலியில் VPN போக்குவரத்துக்கான விதியைச் சேர்க்கிறீர்கள், அதே Linux இயந்திரத்திலிருந்து கோரிக்கையை இயக்குகிறீர்கள், எண்ணிக்கை பூஜ்ஜியத்திலேயே நிற்கிறது. விதி ஒருவேளை சரியானதே. பாக்கெட் அந்த வழியை ஒருபோதும் செல்லவில்லை, ஏனெனில் இயந்திரத்திலேயே உருவாகும் கோரிக்கையை அது முன்னோக்கி அனுப்புவதில்லை. சாக்கெட்டிலிருந்து கம்பி வரை பாக்கெட்டின் வாழ்க்கையைப் பின்தொடர்வது ஏன் என்பதையும், விதி உண்மையில் எங்கே இருக்க வேண்டும் என்பதையும் விளக்குகிறது.
பாக்கெட் எங்கே பிறந்தது என்பதைக் கண்டறியுங்கள்
Netfilter-இன் hook வரிசை மூன்று நிலைகளைப் பிரிக்கிறது, அவற்றில் ஒன்றில் மட்டுமே FORWARD அடங்கும்:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
உள்ளூர் பயன்பாடு OUTPUT பாதையில் தொடங்குகிறது, ஏனெனில் பாக்கெட் இங்கே தோன்றுகிறது என்றும் அது ஒருபோதும் அனுப்புதலுக்கான வேட்பாளர் அல்ல என்றும் கர்னல் ஏற்கனவே தீர்மானித்துவிட்டது. சுரங்கப்பாதை உருவாக்குவது அந்த வகைப்பாட்டை மாற்றாது; சுரங்கப்பாதை என்பது பாக்கெட் வெளியேறக்கூடிய சாதனம், உள்ளூர் வெளியீட்டைக் கடத்தலாக மாற்றும் நிலை அல்ல.
இரண்டு பாக்கெட்டுகள், ஒரு கதை
சுரங்கப்பாதை எழுந்தபின் பயன்பாட்டின் உள் பாக்கெட்டும் மறையாக்கப்பட்ட வெளிப் பாக்கெட்டும் வெவ்வேறு பொருள்கள். உள் பாக்கெட் பயன்பாடு தேர்ந்தெடுத்த இலக்கையும் ஏற்றத்தையும் சுமக்கிறது. வெளிப் பாக்கெட் மறையாக்கப்பட்ட உரையை இணையின் முகவரிக்கும் துறைக்கும் எடுத்துச் செல்கிறது, இயற்பியல் இடைமுகத்தை உண்மையில் கடப்பது அதுவே.
உங்கள் கொள்கை அவற்றில் ஒன்றைப் பற்றியது, தவறானதைத் தேர்ந்தெடுப்பது விதி எதுவும் செய்யாதது போல் தோன்றுவதற்கான பொதுவான காரணம். இணையின் வெளி முகவரியுடன் பொருந்தும் விதி ஒவ்வொரு சுரங்கப்பாதை பாக்கெட்டையும் ஒரே மாதிரி பார்க்கிறது, உள்ளே பயன்பாடு என்ன செய்தாலும். உள் இலக்குடன் பொருந்தும் விதி உங்களுக்கு முக்கியமான போக்குவரத்தைப் பார்க்கிறது, நீங்கள் விதியை நிறுவிய hook-ஐ அந்தப் பாக்கெட் அடைந்தால் மட்டுமே அது இயங்கும்.
namespace எல்லையை நகர்த்துகிறது
கொள்கலன் அடிப்படையை மாற்றாமல் இதைக் கடினமாக்குகிறது. பயன்பாட்டின் கோரிக்கை கொள்கலனின் வலைப்பிணைய namespace-க்குள் உள்ள உள்ளூர் வெளியீடு. புரவலன் அந்தப் போக்குவரத்தை மெய்நிகர் Ethernet இடைமுகத்தில் பெற்று முன்னோக்கி அனுப்பலாம், எனவே கோரிக்கையை உருவாக்கிய செயல்முறை புரவலனின் OUTPUT சங்கிலியை ஒருபோதும் தொடாவிட்டாலும் புரவலனில் உள்ள FORWARD விதி அர்த்தமுள்ளதாக இருக்கலாம்.
hook தேர்ந்தெடுப்பதற்கு முன் விதித்தொகுப்பும் சுரங்கப்பாதையும் உண்மையில் எங்கே வாழ்கின்றன என்பதை உறுதிசெய்யுங்கள். கொள்கலனுக்குள் சுரங்கப்பாதை, கொள்கலனை அதன் வழியாக route செய்த புரவலனில் சுரங்கப்பாதை, தனி namespace-இல் சுரங்கப்பாதை ஆகியவை மூன்று வேறுபட்ட நிலவியல்களும் மூன்று வேறுபட்ட விதி இடங்களும் ஆகும். சாதனத்தைச் சொந்தமாகக் கொண்ட namespace-க்குள் விதிகளைப் படியுங்கள், இயல்புநிலையில் மட்டுமல்ல.
mark உண்மையில் தேவையா என்று கேளுங்கள்
ஒரு இலக்கு முன்னொட்டைச் சுரங்கப்பாதை வழியாக அனுப்புவது இலக்காக இருந்தால், அந்த முன்னொட்டுக்கான route போதுமானதாக இருக்கலாம். முதலில் செல்லுபடியாகும் route-களைச் சரிபார்க்கவும், சேவையகம் தள்ளிய அனைத்தையும் சேர்த்து: திருப்பிவிடப்பட்ட இயல்புநிலை நீங்கள் நினைத்த குறுகிய கொள்கையை விட மிக அதிக போக்குவரத்தை VPN வழியாக அனுப்புகிறது, எவ்வளவு mark செய்தாலும் முடிவு நோக்கத்துடன் ஒத்துப்போகாது.
route வெளிப்படுத்த முடியாத ஒன்றைச் சார்ந்து முடிவு இருக்கும்போது வகைப்பாடு தேவை, எடுத்துக்காட்டாக மூலம், பயனர் அல்லது செயல்முறை. பெறப்படும் போக்குவரத்துக்கு PREROUTING-இல் mark வேலை செய்கிறது. உள்ளூர் போக்குவரத்துக்கு mark, mark வைத்த பிறகு புதிய route தேடலைத் தூண்டக்கூடிய வெளியீட்டு நிலையில் நிகழ வேண்டும். nftables-இல் அது வெளியீட்டு hook-இல் route வகைச் சங்கிலி; சாதாரண வெளியீட்டு வடிகட்டி சங்கிலி மதிப்பை வைத்து route-ஐ மாற்றமின்றி விடும்.
iptables-இல் சமமானது mangle OUTPUT அமைப்பில் வாழ்கிறது, அதே நிபந்தனை பொருந்தும்: mark இருந்த பிறகு route முடிவு மீண்டும் பார்க்கப்பட வேண்டும். பிறகு கொள்கை விதி mark-ஐ நுகர்ந்து பயன்படுத்தக்கூடிய route உள்ள அட்டவணையைச் சுட்ட வேண்டும். conntrack mark வைப்பது மூன்றாவது, தனி செயல்பாடு; அது ஓட்டத்தில் மதிப்பைச் சேமிக்கிறது, அந்த மதிப்பை route படிக்கும்படி தற்போதைய பாக்கெட்டில் தானே வைப்பதில்லை.
தேடலையும் எண்ணிக்கையையும் சேர்த்துச் சரிபார்க்கவும்
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1முகவரியும் mark-உம் எடுத்துக்காட்டுகள், இரண்டு route வினவல்களும் வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. இரண்டாவது, பாக்கெட்டில் அந்த mark இருந்தால் கர்னல் என்ன செய்யும் என்று கேட்கிறது; உங்கள் விதித்தொகுப்பு ஒன்றை வழங்குகிறது என்பதை அது காட்டவில்லை. இதைக் கருதுகோள் சோதனையாகக் கருதுங்கள், கொள்கை இயங்குகிறது என்பதற்கான ஆதாரமாக அல்ல.
பிறகு பாதிப்பில்லாத கோரிக்கையை இயக்கி ஒரே நேரத்தில் இரண்டைப் பாருங்கள்: நீங்கள் தேர்ந்தெடுத்த hook-இல் உள்ள எண்ணிக்கை, பாக்கெட் உண்மையில் எடுத்த வெளியேற்றம். எண்ணிக்கை ஏறி பாக்கெட் வேறெங்கோ வெளியேறினால், mark அல்லது அட்டவணை தவறு. இரண்டும் ஏறவில்லை என்றால் பாக்கெட் அந்த hook-ஐ அடையவே இல்லை, அடுத்த கேள்வி namespace அல்லது பாதை.
இறுதியாக, சோதனையை இயங்குமுறை வெளிப்படுத்தக்கூடியதற்குள் வரம்புபடுத்துங்கள். ஒரு முகவரிக்கான ஒரு route, முகவரிகள் மாறும் சேவைக்கு நிரந்தரக் கொள்கையாகாது. முதலில் பாக்கெட்டின் வரம்பை முடிவு செய்து, மீண்டும் இணைந்த பிறகும் route-உம் mark வடிவமைப்பும் அந்த வரம்பைத் தக்கவைக்குமா எனச் சரிபார்க்கவும்.