உள்ளமை WireGuard: நடு ஹாப் தன் சொந்த போர்ட்டுக்கு பதிலளிக்க முடியாது
நடு ஹாப் எல்லாவற்றையும் ஒரே சுரங்கப்பாதைக்கு அனுப்பும்போது, அதன் உள்வரும் சேவைக்கான பதில்கள் தவறான வழியில் வெளியேறுகின்றன. இடைமுகத்தில் மூல-போர்ட் விதி அதைச் சரிசெய்கிறது.
மூன்று WireGuard ஹாப்கள் பொது முகவரி இல்லாத வலையமைப்பை அடைகின்றன, பிறகு நடு இயந்திரம் கேட்க வேண்டிய போர்ட்டில் பதிலளிப்பதை நிறுத்துகிறது. முன்னோக்கிய சுரங்கப்பாதை இன்னும் செயல்படுகிறது, தொலை ஹோஸ்ட் இன்னும் பதிலளிக்கிறது, வெளியிலிருந்து அமைதியானது நடு சேவையகம் மட்டுமே. இந்தக் கலவை குழப்பமானது, ஏனெனில் அது தானே உருவாக்கியது: நடு ஹாப் தன் சொந்த வழியமைப்பு அட்டவணையைப் பின்பற்றுகிறது, அந்த அட்டவணை அதன் பதில்களைத் தவறான திசையில் அனுப்புகிறது.
நடு பெட்டியுடன் பேசும் வரை செயல்படும் சங்கிலி
ஒரு எடுத்துக்காட்டு சங்கிலியை எடுங்கள்: வாடிக்கையாளர் A UDP 500 இல் சேவையகம் B ஐ அடைகிறார், B UDP 500 இல் சேவையகம் C நோக்கி முன்னேறுகிறது. C தன் ஒரே துணையின் முகவரியிலிருந்து மட்டுமே போக்குவரத்தை ஏற்கிறது, இது அதை ஒரு இலையாக்கி அதன் நடத்தையை எளிமையாக வைத்திருக்கிறது. B இலை அல்ல, இந்தத் தோல்வியின் சுவாரஸ்யமான அனைத்தும் அங்கேயே நடக்கிறது.
இந்த வேறுபாடு முக்கியம், ஏனெனில் இலை மற்றும் நடுப் பாத்திரங்கள் எதிர் திசைகளில் இழுக்கின்றன. இலையால் எந்த விளைவும் இல்லாமல் எல்லாவற்றையும் ஒரே சுரங்கப்பாதைக்கு அனுப்ப முடியும், ஏனெனில் அதைச் சார்ந்து வேறு எதுவும் இல்லை. நடு ஹாப் ஒரே நேரத்தில் வாடிக்கையாளர்களுக்கு முடிவுப் புள்ளியாகவும் தொலைப் பக்கம் நோக்கிய வாடிக்கையாளராகவும் உள்ளது, அந்த இரண்டு வேலைகளுக்கும் வெவ்வேறு வழியமைப்பு தேவை.
பதில் சுரங்கப்பாதை வழியாக வெளியேறுவது ஏன்
B இல், C நோக்கிய இடைமுகம் தொடர்புடைய இயல்புநிலை வழியுடன் AllowedIPs = 0.0.0.0/0 கொண்டுள்ளது. எனவே B உருவாக்கும் ஒவ்வொரு பொட்டலமும் அந்தச் சுரங்கப்பாதைக்குள் செல்கிறது, இன்னும் குறிப்பிட்ட ஒன்று முன்னுரிமை பெறாவிட்டால்.
A இலிருந்து B க்கு முகவரியிடப்பட்ட பொட்டலம் வந்து ஏற்கப்படுகிறது, ஏனெனில் B இலக்கு மற்றும் உள்ளூர் விநியோகம் முதலில் நடக்கிறது. பதில் A இன் பொது முகவரியை நோக்கிய முற்றிலும் புதிய உள்ளூரில் உருவாக்கப்பட்ட பொட்டலம், அந்த இலக்கு சுரங்கப்பாதையின் இயல்புநிலை வழியுடன் பொருந்துகிறது. C அதைப் பெறுகிறது, அந்த முகவரிக்கு உரிமையாளர் அல்ல, அதை வீசிவிடுகிறது.
அறிகுறி ஃபயர்வால் பிரச்சினை அல்லது விசை பொருந்தாமை போலப் படிக்கப்படுகிறது, இங்கே இரண்டும் உண்மை இல்லை. C நோக்கிய சுரங்கப்பாதையில் எடுக்கப்பட்ட பிடிப்பு பதில்கள் தவறான திசையில் செல்வதைக் காட்டுகிறது. அந்த ஒரு கவனிப்பு எவ்வளவு கட்டமைப்பு படிப்பதையும் விட அதிக நேரத்தைச் சேமிக்கிறது, எனவே விசைகளை மாற்றத் தொடங்கும் முன் அதை எழுதி வையுங்கள். பிடிப்பைப் பார்க்காத யாரும் சுரங்கப்பாதையே உடைந்துவிட்டது என்று நினைப்பார்கள்.
குறுகிய பழுது: மூல போர்ட்டுடன் பொருந்தும் கொள்கை விதிகள்
B இன் கேட்கும் சாக்கெட்டிலிருந்து பதில்கள் மூல போர்ட் 500 உடன் வெளியேறுகின்றன. ஒரு கொள்கை விதி அதனுடன் பொருந்தி அந்தப் பொட்டலங்களை வழக்கமான அட்டவணைக்குத் திருப்பி அனுப்பலாம்:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101கொள்கை விதிகள் முன்னுரிமை வரிசையில் பார்க்கப்படுகின்றன, முதன்மை அட்டவணை 32766 இல் உள்ளது, எனவே 100 இல் உள்ள விதி சுரங்கப்பாதையின் இயல்புநிலை வழி பேசுவதற்கு முன் கேட்கப்படுகிறது. வெளியிலிருந்து அணுகக்கூடியதாக இருக்க வேண்டிய ஒவ்வொரு போர்ட்டுக்கும் ஒரு உள்ளீட்டைச் சேர்க்கவும், அதற்கு மேல் எதுவும் இல்லை, இதனால் அனுப்பப்படும் போக்குவரத்து அதற்காகக் கட்டப்பட்ட சுரங்கப்பாதையையே தொடர்ந்து பயன்படுத்தும்.
இந்த உத்தியின் எல்லையை அறியுங்கள். sport தேர்வி உள்ளூரில் உருவாக்கப்பட்ட பொட்டலங்களுடன் பொருந்துகிறது, இது பதில் நிலையைத் துல்லியமாக உள்ளடக்கி, B மற்றொருவருக்காக வெறுமனே அனுப்பும் போக்குவரத்தை வேண்டுமென்றே உள்ளடக்காது. B க்குப் பின்னால் ஹோஸ்ட் செய்யப்படும் சேவைக்கு இன்னும் அதன் சொந்த பதில் தேவை, எதிர்மாறாக நடிப்பது முதல் சேவைக்கு வேலை செய்து இரண்டாவதற்குத் தோல்வியடையும் திருத்தத்தை உருவாக்குகிறது.
விதிக்கு ஒரு உரிமையாளரைக் கொடுங்கள்
கட்டளை வரியில் தட்டச்சு செய்யப்பட்ட விதி அடுத்த முறை இடைமுகம் மீண்டும் கட்டப்படும்போது மறைந்துவிடும். WireGuard அமைப்பில், இடைமுகம் உருவாக்கப்பட்டு நீக்கப்படும் இடத்தில் அதை வையுங்கள்:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100இடைமுகத்தின் உரிமையாளர் NetworkManager, விநியோக ஹூக் அல்லது கொள்கலன் நுழைவுப் புள்ளியாக இருந்தால், அந்த இணை கையால் திருத்தப்பட்ட கோப்புக்கு அல்ல, அந்த உரிமையாளருக்குச் சொந்தம். மீண்டும் இணைந்த பிறகு பயனுள்ள விதிகளைச் சரிபார்க்கவும், முதல் தொடக்கத்திற்குப் பிறகு மட்டும் அல்ல, ஏனெனில் முதல் தொடக்கம் எப்போதும் வேலை செய்யும் நிலை.
மாற்றுகளை நேர்மையாக ஒப்பிடுங்கள்
மூல-போர்ட் விதி நான்கு வெளியேறும் வழிகளில் ஒன்று, அவற்றில் மிகக் குறுகியது. சுரங்கப்பாதைக் கொள்கையை அறவே தொடாத நன்மை அதற்கு உண்டு, அதனாலேயே பிந்தைய மாற்றங்களில் அது தப்பிப் பிழைக்கிறது. குறுகிய திருத்தங்கள் பொருந்தாமல் போகும்போது சத்தமாகத் தோல்வியடைகின்றன, அதேசமயம் பரந்த விதிவிலக்கு அதன் காரணம் மறைந்து நீண்ட காலத்திற்குப் பிறகும் அமைதியாக வேலை செய்கிறது. இரண்டு ஆண்டுகளுக்குப் பிறகு பெட்டி வேறொருவருக்குச் சொந்தமாகும்போது அந்த வேறுபாடு நேர்த்தியை விட முக்கியம்.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
தேர்ந்தெடுத்த பிறகு இரு முனைகளிலிருந்தும் சரிபார்க்கவும். A இலிருந்து, B இன் போர்ட்டுக்கு ஒரு இணைப்பைத் தொடங்கி சிறிது நேரம் பிஸியாக வைத்திருங்கள். B இல், ip route get <address-of-A> sport 500 போன்ற ஒன்றைக் கொண்டு கர்னலை பதில் பாதையை நியாயப்படுத்தச் செய்து, அது சுரங்கப்பாதை அல்ல WAN இடைமுகத்தைக் குறிப்பிடுவதை உறுதிப்படுத்துங்கள். அதன் பிறகு, C க்குப் பின்னால் உள்ள ஏதோ ஒன்று இன்னும் சங்கிலி வழியாகப் பதிலளிப்பதைச் சரிபார்க்கவும், இது விதிவிலக்கு பைபாஸாக மாறாமல் குறுகியதாகவே இருந்ததை நிரூபிக்கிறது. இறுதியாக, போர்ட்களை வடிவமைப்புக் குறிப்புகளில் பதிவு செய்யுங்கள், இல்லையெனில் அடுத்த ஆபரேட்டர் இதை வேறு சேவையில் மீண்டும் கண்டுபிடிப்பார்.