VPN சப்நெட்டுக்கான போர்ட் ஃபார்வேர்ட்டில் SNAT ஐப் பயன்படுத்த வேண்டுமா?

ரவுட்டரின் சொந்த VPN கிளையண்டுக்குப் பின்னால் இருக்கும் ஹோஸ்ட்டுக்கு போர்ட்டை ஃபார்வேர்ட் செய்வது ஃபயர்வால் சிக்கல் போலத் தோன்றும் வகையில் தோல்வியடைகிறது, ஏனெனில் கோரிக்கை தெளிவாக வந்தடைகிறது. சேவை ஒரு இணைப்பைப் பதிவு செய்கிறது, கிளையண்ட் காத்திருக்கிறது, எதுவும் திரும்பி வரவில்லை. இலக்கு மொழிபெயர்ப்பு தன் வேலையைச் செய்தது; திரும்பும் பாக்கெட்டே காணாமல் போன பகுதி. ரவுட்டரில் ஒரு தேர்ந்தெடுக்கப்பட்ட மூல-NAT விதி இதைச் சரிசெய்கிறது, சுவாரஸ்யமான பகுதி அந்த விதி எவ்வளவு குறுகலாக இருக்க முடியும் என்பதைத் தீர்மானிப்பதுதான்.

பதில் வேறு வழியை எடுப்பது ஏன்

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

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

நம்பத் தகுந்த அளவுக்குக் குறுகிய மூல விதி

தொலை ஹோஸ்ட் பதிலளிக்கும் மூலமாக ரவுட்டரை ஆக்குங்கள். இந்த அமைப்பில் WAN முகவரி 203.0.113.24, LAN 192.168.88.0/24, ரவுட்டரின் டன்னல் முகவரி 172.20.5.1, மற்றும் சேவை 172.20.5.40:8443 இல் பதிலளிக்கிறது. கீழேயுள்ள விதி இலக்கு மொழிபெயர்ப்புக்குப் பிந்தைய பாக்கெட்டுடன் பொருந்துகிறது, அதனால்தான் பொது முகவரிக்குப் பதிலாக மொழிபெயர்க்கப்பட்ட முகவரியைக் குறிப்பிடுகிறது. அதில் எதுவும் கிளையண்டின் முகவரியைச் சார்ந்திருக்கவில்லை, அதுவே முக்கிய விஷயம்.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

எப்போது முழுமையான மறைப்பு நேர்மையான தேர்வு

ரவுட்டர் பல சேவைகளை ஒரே VPN சப்நெட்டுக்கு ஃபார்வேர்ட் செய்தால், ஒவ்வொரு சேவைக்கான விதி யாரும் பராமரிக்காத பட்டியலாக மாறும். டன்னல் இடைமுகத்தை விட்டு வெளியேறும் அனைத்தையும் மறைப்பது எளிமையானதும் முன்னறிவிக்கத்தக்கதும் ஆகும், அதன் விலை என்னவென்றால் அசல் கிளையண்ட் எதிர்ப்பக்கத்தின் ஒவ்வொரு ஹோஸ்ட்டிலிருந்தும் மறைக்கப்படுகிறது. அங்குள்ள பதிவுகள் பண்புக்கூறுக்குப் பயன்படுத்தப்படாதபோது அதைத் தேர்ந்தெடுக்கவும்; பயன்படுத்தப்படும்போது குறுகிய விதியை வைத்திருங்கள்.

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

வெளியிடும் முன் கவுண்டர்களைச் சரிபார்க்கவும்

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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