CGNAT போர்ட்களைத் தடுக்கும்போது VPS வழியாக வீட்டு சேவையகத்தை வெளியிடுவது

நான் வெளியிலிருந்து தொடங்கினேன், ஒரு பயனர் செய்வது போல: பெயரை மொபைல் தரவில் தொலைபேசியின் உலாவியில் தட்டச்சு செய்து, இணைப்பு நேரம் முடியும் வரை தொங்கியிருப்பதைப் பார்த்தேன். பெயர் தீர்க்கப்பட்டது, அதாவது DNS சரியாக இருந்தது. வீட்டு ரவுட்டரின் போர்ட்-ஃபார்வர்டிங் பக்கமும் முட்டுச் சந்தாக இருந்தது, ஏனெனில் அதன் WAN முகவரி 100.64.31.42 காட்டியது, இது ஒரு வழங்குநர் என்னை இணையத்திலிருந்து அனுப்பும் முகவரி அல்ல. இந்த எண் முழு கோளாறையும் விளக்குகிறது: இணைப்பு carrier-grade NAT-க்குப் பின்னால் உள்ளது, எனவே சுரங்கப்பாதையின் எனது பக்கத்திலுள்ள பொது முகவரி வழங்குநருக்குச் சொந்தம். அடுத்து நான் அந்தச் சிக்கிய தாவலிலிருந்து பதிலளிக்கும் சேவை வரை நடந்த பாதை வருகிறது.

வாடிக்கையாளரிலிருந்து தொடங்கி உள்ளே செல்

எந்த விதியையும் மாற்றுவதற்கு முன் சங்கிலி எங்கு நிற்கிறது என்பதை நிரூபிக்கவும். மடிக்கணினியில் நான் dig +short files.example.net இயக்கி VPS முகவரியைத் திரும்பப் பெற்றேன், இது எனது இயந்திரத்தில் பழைய DNS-ஐ நீக்கியது. பின்னர் curl -v --connect-timeout 5 files.example.net:5022 நிராகரிக்கப்படுவதற்குப் பதிலாக நேரம் முடிந்து நின்றது. இந்த வேறுபாடு முக்கியம்: நேரம் முடிவது பொதுவாக பாக்கெட்டுகள் வழியில் வீசப்படுவதைக் குறிக்கிறது, அதே சமயம் நிராகரிப்பு என்பது ஏதோ பதிலளித்து இல்லை என்றது என்பதாகும்.

உள்ளே அடுத்த படி VPS தானே. ss -ltnp 5022-இல் கேட்கும் எதையும் காட்டவில்லை, இது DNAT விதி உருவாகும் முன் எதிர்பார்க்கப்பட்டது. அதே இயந்திரத்தில் wg show (அல்லது OpenVPN-க்கு ip -br a show tun0) வீட்டு peer இயங்குகிறது என்பதையும் அதற்கு புதிய handshake உள்ளது என்பதையும் உறுதிப்படுத்தியது. peer வேலை செய்யாவிட்டால் எந்த NAT விதியும் உதவாது, வீட்டு ரவுட்டரின் VPN பக்கத்திலுள்ள பச்சை விளக்கு எதையும் குறிக்காது.

வீட்டு இணைப்பு உண்மையில் CGNAT-க்குப் பின்னால் உள்ளது என்பதை உறுதிப்படுத்து

ரவுட்டர் தன் WAN இடைமுகத்தில் தெரிவிக்கும் முகவரியை வெளிப்புறச் சேவை காண்பதோடு ஒப்பிடவும். 100.64.0.0/10-ல் உள்ள அனைத்தும், அதாவது 100.64.x.x முதல் 100.127.x.x வரை, RFC 6598-இன் பகிரப்பட்ட முகவரி வரம்பு மற்றும் இணையத்திலிருந்து அணுக முடியாது. ரவுட்டர் சாதாரண தனிப்பட்ட முகவரி இருப்பதாகக் கூறி, பொது தேடல் தொடர்பற்ற ஒன்றைத் திருப்பித் தந்தாலும் அதே முடிவுக்கு வருவீர்கள். CGNAT இணைப்பில் அடுத்த lease வரை மட்டுமே நீடிக்கும் பொது முகவரியும் இருக்கலாம், எனவே போர்ட் ஃபார்வர்டிங் ஒரு மணி நேரம் வேலை செய்வது போலத் தோன்றி பின்னர் அமைதியாக இறக்கிறது.

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

பெயரை VPS முகவரிக்கு காட்டு

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

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

ஒரு போர்ட் DNAT-இல், SSH 22-இல் இருக்கட்டும்

நேரடி விருப்பம் VPS-இல் இலக்கு NAT. இயங்கும் கர்னலுக்கு forwarding-ஐ இயக்கி, விதியில் வீட்டு சேவையகத்தின் சுரங்க முகவரியை வைக்கவும், அதன் LAN முகவரியை அல்ல:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

VPS-க்கு SSH-ஐ 22-இல் விடுங்கள், மற்றொரு போர்ட்டை, எடுத்துக்காட்டாக 5022-ஐ, வீட்டு இயந்திரத்திற்கு அனுப்புங்கள். 22-ஐ அணைந்த இயந்திரத்திற்கு அனுப்பினால் அதைச் சரிசெய்யக்கூடிய ஒரே பாதையை இழப்பீர்கள். அதே தர்க்கம் ப்ராக்ஸிக்கும் பொருந்தும்: VPS-இன் நிர்வாகப் போர்ட்டை relay விதிகளுக்கு வெளியே வைக்கவும்.

விதிகள் வேலை செய்யத் தொடங்கியதும் அவற்றை நிரந்தரமாக்குங்கள். Debian அல்லது Ubuntu-வில் apt install iptables-persistent மற்றும் பின்னர் netfilter-persistent save அவற்றை /etc/iptables/rules.v4-இல் எழுதுகின்றன. firewalld உள்ள புரவலனில் அதற்கு இணையானது மண்டலத்தில் நிரந்தர போர்ட் ஃபார்வர்டிங், அது நடைமுறைக்கு வரும் முன் firewall-cmd --reload தேவை. நினைவகத்தில் மட்டும் வாழும் விதிகள் வழங்குநரின் முதல் பராமரிப்பு மறுதொடக்கத்தில் மறைந்துவிடும், பொதுவாக மோசமான நேரத்தில்.

திரும்பும் பாதையைச் சரிசெய் அல்லது அதன் தேவையைத் தவிர்

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

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

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

அல்லது VPS மூலத்தை மீண்டும் எழுதட்டும், பதிலுக்கு அது அடையக்கூடிய முகவரி இருக்கட்டும், conntrack அதை வெளியேறும் போது புரட்டட்டும்:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

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

முழுப் பாதையையும் வெளியிலிருந்து சரிபார்

VPS-உம் இல்லாத, வீடும் இல்லாத வலையமைப்பிலிருந்து சரிபார்க்கவும்: மொபைல் தரவில் தொலைபேசி, அல்லது வேறெங்கோ மலிவான shell. nc -vz files.example.net 5022 வெற்றிகரமான இணைப்பைத் தெரிவிக்க வேண்டும், openssl s_client -connect files.example.net:443 -servername files.example.net பொது பெயருக்கான சான்றிதழைக் காட்ட வேண்டும். பின்னர் வழங்குநரின் பாதுகாப்புக் குழு அல்லது மேக ஃபயர்வாலைச் சரிபார்க்கவும். ஒருபோதும் பாக்கெட்டைக் காணாத DNAT விதி பொதுவாக புரவலனுக்கு ஒரு அடுக்கு மேலே தடுக்கப்படும்.

இறுதியாக, சுரங்கம் விழும்போது என்ன நடக்கும் என்று முடிவு செய்யுங்கள். DNAT விதி இணைப்புகளை ஏற்றுக்கொண்டே இருக்கும், அவற்றை அமைதியாக இறந்த சுரங்கத்திற்குள் செலுத்தும், இது பழுதடைந்த சேவை போலவே தோன்றும். VPS-இல் peer இயங்காத வரை போர்ட்டை நிராகரிக்கும் ஆரோக்கியச் சோதனை சில வரிகள்தான் செலவு, ஒரு மணி நேர ஊகத்தை மிச்சப்படுத்துகிறது. அதன் பிறகு விதிகளைத் திருத்துவதை நிறுத்தி, அதை நம்புவதற்கு முன் ஒரு நாள் கவனியுங்கள்.