போர்ட் ஃபார்வர்டு vs VPN அணுகல்: பாக்கெட் உண்மையில் எங்கே செல்கிறது

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

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

DNAT விதி இலக்கை மீண்டும் எழுதி அங்கேயே நிற்கிறது

Linux நுழைவாயிலில் சேவையை வெளியிடுவது என்பது nat அட்டவணையின் PREROUTING சங்கிலியில் ஒரு விதி, அல்லது nftables-ல் அதற்கு இணையானது. விதி பொது முகவரி மற்றும் போர்ட்டுடன் பொருந்தி, பின்னர் இலக்கை பயன்பாட்டின் தனிப்பட்ட முகவரிக்கு மீண்டும் எழுதுகிறது. மூல முகவரி, மூல போர்ட் மற்றும் பேலோட் தொடப்படாமல் இருக்கும், conntrack வரைபடத்தைப் பதிவு செய்கிறது, எனவே பதில்கள் வெளியேறும்போது மீண்டும் எழுதப்படும். இந்த நடத்தை RFC 3022-ல் விவரிக்கப்பட்ட பாரம்பரிய முகவரி மொழிபெயர்ப்பு மாதிரி.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

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

விதி பின்னர் சந்திக்கும் தோல்வி முறைகளையும் நிர்ணயிக்கிறது. நுழைவாயில் அனுப்பினாலும் பயன்பாட்டின் ஹோஸ்ட்டுக்கு வாடிக்கையாளருக்குத் திரும்பும் பாதை இல்லாவிட்டால், பதில்கள் தவறான மூலத்துடன் வெளியேறி கைக்குலுக்கல் நிற்கிறது. இரண்டாவது விதி முதலில் பொருந்தினால், வரிசையே முடிவை நிர்ணயிக்கிறது, iptables -t nat -L -n -v எந்த விதி பாக்கெட்டை எடுத்தது என்பதை நிரூபிக்கும் கணக்கிகளைக் காட்டுகிறது.

சுரங்கப்பாதை கேட்பான் காண்பதற்கு முன் பாக்கெட்டைச் சுற்றுகிறது

VPN பயன்பாட்டை வெளியிடுவதே இல்லை. வாடிக்கையாளர் நுழைவாயிலின் பொது முகவரிக்கு இலக்கு வைக்கப்பட்ட வெளிப் பாக்கெட்டை உருவாக்கி, உள்ளே உள்ள பாக்கெட்டை அதற்குள் மறையாக்கி, நுழைவாயில் அதை மறைகுறியாக்கம் செய்து உள் பாக்கெட்டைத் தனிப்பட்ட இலக்கிற்கு வழிமாற்றுகிறது. WireGuard-ல் வெளி போக்குவரத்து UDP, பொதுவாக உயர் போர்ட்டில்; OpenVPN TCP 443-ல் இருந்தால் பாதையைக் கவனிக்கும் எதற்கும் வெளிப் பாக்கெட் TLS போலத் தெரிகிறது.

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

சுற்றுவது தலைப்பு இடத்தைச் செலவழிக்கிறது, அளவிடக்கூடிய விளைவுள்ள ஒரே பொறிமுறை நிலை வேறுபாடு அதுவே. வெளி IP தலைப்பு மற்றும் UDP மற்றும் WireGuard-இன் சொந்தத் தலைப்பு பாதையின் MTU-விலிருந்து உண்கின்றன, எனவே பெரிய பாக்கெட்டுகள் பிரிக்கப்பட வேண்டும் அல்லது உள் TCP ஸ்டாக் அதன் MSS-ஐக் குறைக்க வேண்டும். ஃபார்வர்டு செய்யப்பட்ட பாதையில் வேலை செய்யும் பரிமாற்றம், இடைப்பட்ட சாதனம் சிறிய MTU-ஐ அறிவிக்கும் ICMP-ஐ விட்டெறிந்தால் சுரங்கப்பாதையில் நிற்கலாம்.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

வெளிப்பாடு நுழைவில் தீர்மானிக்கப்படுகிறது, சைஃபரால் அல்ல

இரண்டு வடிவமைப்புகளும் ஒரே TLS கேட்பானில் முடிகின்றன, எனவே இரண்டும் ஒரே சான்றிதழ், ஒரே நெறிமுறை பதிப்புகள் மற்றும் ஒரே பயன்பாட்டு உள்நுழைவைப் பெறுகின்றன. மாறுவது கைக்குலுக்கலைத் தொடங்க யாருக்கு அனுமதி உண்டு என்பதுதான். பொது ஃபார்வர்டில், 203.0.113.10:443-ஐ அடையும் எந்த ஹோஸ்ட்டும் உங்கள் பயன்பாட்டு அங்கீகாரம் பார்க்கப்படுவதற்கு முன்பே TCP கைக்குலுக்கல் மற்றும் TLS ClientHello பெறுகிறது. சுரங்கப்பாதை வழி அணுகலில், நுழைவாயில் சுரங்கத்திற்குள் வழிமாற்றும் முகவரிகளிலிருந்து மட்டுமே கேட்பானை அடைய முடியும், அந்நியனின் SYN நுழைவாயில் கொள்கையில் இறக்கிறது.

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

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

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

ss கேட்பான் 0.0.0.0-உடன் பிணைக்கப்பட்டுள்ளதாகக் காட்டினால், வழிமாற்றம் மற்றும் ஃபயர்வால் கொள்கை அனுமதிக்கும் எந்த இடத்திலிருந்தும் பயன்பாட்டை அடைய முடியும், ஃபார்வர்டு நுழைவதற்கான ஒரு வழி மட்டுமே. தனிப்பட்ட முகவரியுடன் பிணைப்பது, அல்லது ஃபயர்வாலில் மூல வரம்பைக் கட்டுப்படுத்துவது, VPN தேர்ந்தெடுப்பிலிருந்து தனி முடிவு, வெளிப்பாட்டை உண்மையில் குறைப்பது அந்த முடிவே.

பாதையை அளவிடுங்கள், லேபிளை அல்ல

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

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

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

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

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

தொடர்புடைய கட்டுரைகள்