SNAT, DNAT மற்றும் Masquerade: ஒவ்வொரு VPN NAT விதியும் என்ன செய்கிறது

VPN நுழைவாயிலின் இரு பக்கங்களிலும் பதிவை வைக்கவும், ஒரு ஓட்டம் நான்கு வெவ்வேறு முகவரிகளைக் காட்டலாம். மூல NAT பாக்கெட் எங்கிருந்து வருவதாகக் கூறுகிறது என்பதை மீண்டும் எழுதுகிறது; இலக்கு NAT அது எங்கே செல்கிறது என்பதை மீண்டும் எழுதுகிறது. Masquerade மூன்றாவது திசை அல்ல, நிலையான மதிப்புக்குப் பதிலாக வெளிச்செல்லும் இடைமுகத்தின் முகவரியை எடுக்கும் மூல-NAT விதி. மூன்றில் உங்களுக்கு உண்மையில் எது தேவை என்று பெயரிடுங்கள், பெரும்பாலான «VPN உடைந்தது» டிக்கெட்டுகள் திரும்பும் பாதை பற்றிய கேள்வியாகச் சுருங்கும்.

ஒவ்வொரு விதியும் எதை மீண்டும் எழுதுகிறது

மூல NAT, பொதுவாக SNAT என எழுதப்படும், ஓட்டம் ஒரு திசைவழியாக்கி அல்லது நுழைவாயிலை விட்டு வெளியேறும்போது அதன் மூல முகவரியை மாற்றுகிறது. பெறும் சேவை மொழிபெயர்க்கப்பட்ட முகவரிக்குப் பதிலளிக்கிறது, மொழிபெயர்க்கும் பெட்டி அந்த இணைப்புக்காக வைத்திருந்த நிலையைப் பயன்படுத்தி மாற்றத்தை மீளச் செய்கிறது. Linux இல் அந்த நிலை conntrack இல் வாழ்கிறது, அதனால் conntrack -L அசல் மற்றும் பதில் ஜோடிகளை அருகருகே அச்சிடுகிறது.

இலக்கு NAT, DNAT, அதற்குப் பதிலாக இலக்கை மாற்றுகிறது. UDP 51820 இல் பொது முகவரிக்கு அனுப்பப்பட்ட பாக்கெட்டை 10.8.0.2:51820 இல் உள்ள உள் WireGuard சேவையகத்திற்கு மீண்டும் எழுதலாம். வீட்டு திசைவழியாக்கி அல்லது மேகக்கணி சுமை சமநிலைப்படுத்தி VPN கேட்பியை இப்படித்தான் வெளியிடுகிறது, அது சுரங்கப்பாதை பின்னர் எதைச் சுமக்கலாம் என்பதைப் பற்றி எதுவும் கூறவில்லை.

Masquerade SNAT குடும்பத்தைச் சேர்ந்தது. விதி எந்த முகவரியையும் பெயரிடவில்லை; பாக்கெட் வெளியேறும் நேரத்தில் வெளிச்செல்லும் இடைமுகத்திடம் உள்ள முகவரியைப் பயன்படுத்துகிறது. Linux அதற்கு அதன் சொந்த இலக்கைத் தருகிறது, DHCP அல்லது PPPoE மூலம் முகவரி பெறும் WAN இடைமுகத்தில் இது வழக்கமான தேர்வு.

வரைபடம் எங்கே வாழ்கிறது என்பது தோல்வியைத் தீர்மானிக்கிறது

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

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

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

Masquerade அல்லது வெளிப்படையான SNAT

இரண்டையும் அவை வாக்களிப்பதை வைத்து ஒப்பிடுங்கள். Masquerade வெளியேறும் முகவரியைத் தேர்ந்தெடுக்கிறது, வெளிப்படையான SNAT அதைப் பிணைக்கிறது. நிலையான பொது முகவரி உள்ள நுழைவாயிலில் பிணைப்பு பதிவுகள் மற்றும் கூட்டாளர் அனுமதிப் பட்டியல்களுக்கு ஒரு கணிக்கக்கூடிய மதிப்பைத் தருகிறது. இயங்கும் WAN இணைப்பில் பிணைக்கப்பட்ட SNAT முகவரி குத்தகை மாறும் தருணத்தில் தவறாகும், Masquerade அதே சந்தர்ப்பத்திற்காகவே கட்டப்பட்டது.

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

கொள்கை அடிப்படையிலான IPsec இல் இது அதிகம் கடிக்கிறது. strongSwan இன் முன்னனுப்பு வழிகாட்டி IP முன்னனுப்பை இயக்கி வாடிக்கையாளர்களுக்கு மூல-NAT விதியைச் சேர்ப்பதை படிப்படியாகக் காட்டுகிறது, அதே ஆவணம் அசல் முகவரியைத் தக்கவைக்க வேண்டிய போக்குவரத்தை விலக்குவதையும் உள்ளடக்குகிறது. பாதுகாப்புக் கொள்கை பொருந்தும் முன் மூலத்தை மொழிபெயர்த்தால், சுரங்கப்பாதை மேலெழலாம் ஆனால் போக்குவரத்து தொடர்ந்து விழும், ஏனெனில் பாக்கெட் இனி பேச்சுவார்த்தை செய்யப்பட்ட தேர்வியுடன் ஒத்துப்போகவில்லை.

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

Linux நுழைவாயிலில் விதிகளைப் படித்தல்

10.8.0.0/24 இல் வாடிக்கையாளர்களும் eth0 எனப் பெயரிடப்பட்ட WAN இடைமுகமும் உள்ள தொலை அணுகல் நுழைவாயிலுக்கு முன்னனுப்பு இயக்கப்பட்டதும் ஓட்டத்தை அனுமதிக்கும் வடிகட்டிக் கொள்கையும் தேவை, அதன் பின்னரே எந்த NAT விதியும் உதவ முடியும். iptables பதிப்பு இரு திசைகளையும் nat அட்டவணையில் வைத்திருக்கிறது:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables வடிவம் அதே இரு கொக்கிகளைப் பெயரிடப்பட்ட இடைமுகம் மற்றும் வெளிப்படையான சங்கிலியுடன் பயன்படுத்துகிறது:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

இரு துண்டுகளும் வடிகட்டி சங்கிலி முன்னனுப்பப்பட்ட ஓட்டத்தை ஏற்கனவே ஏற்றுக்கொள்கிறது என்று கருதுகின்றன. NAT அனுமதி விதி அல்ல, சரியாக மொழிபெயர்க்கப்பட்ட பாக்கெட் கூட ஒரு அட்டவணை கழித்து நிராகரிக்கப்படலாம். conntrack -L மூலம் நேரடி வரைபடத்தை உறுதிசெய்து, nft list ruleset அல்லது iptables-save -t nat மூலம் என்ன ஏற்றப்பட்டுள்ளது என்பதை உறுதிசெய்து, பின்னர் முகவரி உண்மையில் மாறுவதைக் காண இரு இடைமுகங்களிலும் பதிவு செய்யுங்கள்.

மோசமான விதி போலத் தோன்றும் தோல்வி முறைகள்

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

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

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

விதியைச் சேமிக்கும் முன் சரிபார்ப்புப் பட்டியல்

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

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