CGNAT பின்னால் இருந்து VPN கிளையண்ட் போர்ட்டை வெளியிடுங்கள்: சரிபார்ப்பு பட்டியல்

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

சேவையகம் எதையும் அனுப்புமா என்பதை உறுதிசெய்யுங்கள்

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

இயங்கும் கர்னலில் அமைப்பது மறுதொடக்கத்தின் குறுக்கே அமைப்பதற்குச் சமமல்ல. net.ipv4.ip_forward=1 ஐ /etc/sysctl.d/ கீழ் உள்ள கோப்பில் எழுதுங்கள், sysctl --system ஐ இயக்குங்கள், பின்னர் கோப்பு எடுக்கப்பட்டதாக நம்புவதற்குப் பதிலாக மதிப்பை மீண்டும் படியுங்கள். தனது சொந்த பிணைய பெயர்வெளியை நிர்வகிக்கும் கொள்கலனுக்கு அந்த வெளிக்குள் அதே மதிப்பு தேவை, ஹோஸ்ட்டில் மட்டும் அல்ல.

மீண்டும் படித்த பிறகும் பூஜ்யமாக இருந்தால், இங்கேயே நிறுத்துங்கள். கீழே எதுவும் வேலை செய்யாது.

எந்த விதியும் அதைக் குறிப்பிடுவதற்கு முன் சுரங்கப்பாதையின் முகவரியை நிலைநிறுத்துங்கள்

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

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

இரு திசைகளிலும் மொழிபெயர்ப்பீர்கள்

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

iptables -t nat -S உடன் இரண்டு விதிகளையும் மீண்டும் படித்து, இடைமுகத்தின் பெயர் பொது முகவரியைச் சுமப்பதுதானா என்பதை உறுதிசெய்யுங்கள். ஏற்கனவே nftables மூலம் வடிகட்டும் ஹோஸ்ட்டில், கருவிகளைக் கலக்காமல் பொருந்தும் முகவரிக் குடும்பத்தின் nftables NAT சங்கிலியில் மொழிபெயர்ப்பை எழுதுங்கள்.

வடிகட்டி அட்டவணையைக் கடக்க விடுங்கள்

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

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

எதையும் சேர்ப்பதற்கு முன் FORWARD சங்கிலியின் கொள்கையைச் சரிபாருங்கள், ஏனெனில் முன்கூட்டிய DROP-இன் வரிசையே உங்கள் விதி எப்போதாவது பரிசீலிக்கப்படுமா என்பதைத் தீர்மானிக்கிறது. வடிகட்டுதல் nftables-ல் வாழும் ஹோஸ்ட்டில், சமமான விதியை inet அட்டவணையின் forward கொக்கியில் சேர்த்து, அடிப்படைச் சங்கிலி உள்ளூர் உள்ளீட்டை மட்டுமல்ல, உண்மையில் அனுப்பப்படும் போக்குவரத்தைப் பார்க்கிறது என்பதை உறுதிசெய்யுங்கள். புதிய விதியின் பாக்கெட் கவுண்டர் பூஜ்யத்திலேயே இருக்க NAT கவுண்டர்கள் உயர்ந்தால், பாக்கெட் உங்கள் விதிக்கு முன்பே நிராகரிக்கப்படுகிறது. அது சங்கிலிகளின் வரிசையைப் படிக்கும் சமிக்ஞை, அதே விதியின் இரண்டாவது நகலைச் சேர்ப்பதல்ல.

வெளி வலையமைப்பிலிருந்து இதை நிரூபியுங்கள்

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

tcpdump -ni any port 29443
conntrack -L | grep 29443

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

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