போர்ட் 80 மற்றும் 443 விதிகள் உலாவியை VPN வழியாக அனுப்புவதில்லை
போர்ட் பொருத்தம் TCP ஓட்டங்களைத் தேர்ந்தெடுக்கிறது, உலாவியை அல்ல. HTTP/3 UDP-இல் இயங்குகிறது, DNS வேறு பாதை எடுக்கலாம், மேலும் புதுப்பிப்பான் நீங்கள் எழுதிய அதே விதியுடன் பொருந்துகிறது.
யாரோ உலாவி சுரங்கப்பாதையைப் பயன்படுத்த வேண்டும் என்று கேட்கிறார்கள், பதில் இலக்குப் போர்டுகள் 80 மற்றும் 443 உடன் பொருந்தும் ஃபயர்வால் விதியாகத் திரும்பி வருகிறது. அது துல்லியமாகத் தெரிகிறது, ஆனால் இல்லை. போர்ட் பொருத்தம் பாக்கெட்டுகளை அவற்றின் போக்குவரத்துத் தலைப்பின் அடிப்படையில் தேர்ந்தெடுக்கிறது, எந்த நிரல் சாக்கெட்டைத் திறந்தது என்பதன் அடிப்படையில் அல்ல, மேலும் நவீன உலாவல் TCP-இல் அந்த இரண்டு போர்டுகளுக்கு மட்டுப்படுத்தப்படவில்லை. விதி நீங்கள் சேர்க்க விரும்பிய சில டிராஃபிக்கைத் தவறவிட்டு, நீங்கள் ஒருபோதும் தொட நினைக்காத டிராஃபிக்கைப் பிடிக்கும். அதை எழுதுவதற்கு முன், மூன்று வெவ்வேறு எல்லைகளில் உங்களுக்கு உண்மையில் எது வேண்டும் என்பதை முடிவு செய்யுங்கள்.
விதி போக்குவரத்து வகுப்பை விவரிக்கிறது, பயன்பாட்டை அல்ல
Linux-இல், இலக்குப் போர்ட் பொருத்தம் TCP தலைப்பை மட்டுமே பரிசோதிக்கிறது, அதற்கு மேல் எதையும் இல்லை. அந்தப் பாக்கெட்டுகளைக் குறித்து கொள்கை வழித்தடத்தால் வழிநடத்துவது ஆவணப்படுத்தப்பட்டபடியே செயல்படுகிறது, மேலும் அந்த இயந்திரங்களில் எதற்கும் பேலோடின் பொருள் என்ன அல்லது எந்தச் செயல்முறை அதை அனுப்பியது என்று தெரியாது. குறி என்பது பாக்கெட்டில் ஒட்டப்பட்ட எண், பயன்பாட்டில் ஒட்டப்பட்ட அடையாளம் அல்ல.
nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100உடனே இரண்டு விளைவுகள் வருகின்றன. TCP 443 உடன் தொடர்பு கொள்ளும் மென்பொருள் புதுப்பிப்பான் உலாவியைப் போலவே நடத்தப்படுகிறது, அது சரியாக இருக்கலாம் அல்லது அடுத்த புதுப்பிப்புச் சுழற்சிக்குக் காத்திருக்கும் இடையூறாக இருக்கலாம். மேலும் வேறொரு போர்ட்டில், சொல்லுங்கள் 8443, வேண்டுமென்றே வெளியிடப்பட்ட வலைச் சேவை விதியிலிருந்து முற்றிலும் வெளியே விழுகிறது, இருப்பினும் அது இன்னும் பயனருக்கு முக்கியமான அதே வலை டிராஃபிக் தான்.
தேவை உண்மையில் அந்தப் போர்டுகளைப் பற்றியதாக இருக்கும்போது எண்கள் சட்டபூர்வமான தேர்வுகளாகும். டிக்கெட்டில் «உலாவி» என்று எழுதி, விதித் தொகுப்பில் போர்ட் வரம்பு செயல்படுத்தப்படும்போது அவை கற்பனையாகின்றன. இந்த இடைவெளி ஆவணப்படுத்தலின் நுணுக்கம் அல்ல. இது மதிப்பாய்வில் நீங்கள் பாதுகாக்கக்கூடிய விதிக்கும் யாரும் சோதிக்க முடியாத விதிக்கும் இடையிலான வேறுபாடு.
HTTP/3 உங்கள் TCP விதியை அமைதியாக விட்டுவிடுகிறது
HTTP/3 QUIC-இன் மேல் இயங்குகிறது, QUIC UDP-இல் எடுத்துச் செல்லப்படுகிறது. TCP உடன் மட்டும் பொருந்தும் விதி அதைப் பார்க்க முடியாது, எனவே உங்கள் சோதனைப் பக்கத்தைக் கடக்கும் அதே உலாவி பின்னர் ஒரு கோரிக்கையை UDP வழியாக அனுப்பி, யாரும் அமைப்பை மாற்றாமல் சுரங்கப்பாதையைத் தவிர்க்கலாம். RFC 9114 HTTP/3-ஐ QUIC அடிப்படையிலான நெறிமுறையாக விவரிக்கிறது, மேலும் வழக்கமான பயன்பாட்டில் QUIC இயல்புநிலை போர்ட் 443 கொண்ட UDP-ஐப் பயன்படுத்துகிறது.
குறிப்பிட்ட உலாவி HTTP/3-ஐ முயற்சிக்குமா என்பது அதன் உள்ளமைவு, தளம் மற்றும் முந்தைய முயற்சி வெற்றியடைந்ததா என்பதைப் பொறுத்தது. அதனால் நினைவில் இருந்து அதைப் பற்றி வாதிடுவது மோசம். அதற்குப் பதிலாக கருவியிடம் கேளுங்கள்:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'curl வரி பேச்சுவார்த்தை செய்யப்பட்ட பதிப்பை அச்சிடுகிறது, எனவே 3 UDP பாதை பயன்படுத்தப்பட்டதை உறுதிப்படுத்துகிறது. பின்னர் சாக்கெட் பட்டியல் அந்த இணைப்பு சுரங்கப்பாதை இடைமுகத்துடன் இணைக்கப்பட்டதா அல்லது இயற்பியல் ஒன்றுடனா என்பதைக் காட்டுகிறது. உங்கள் curl கட்டமைப்பில் HTTP/3 இல்லை என்றால், கொடி அமைதியாகப் பின்வாங்காமல் சத்தமாகத் தோல்வியடைகிறது, அதுவே அதன் சிறிய கருணை.
DNS நீங்கள் எடுக்க வேண்டிய தனி முடிவு
வலை டிராஃபிக்கிற்கான போர்ட் விதி பெயர் தீர்வு பற்றி எதுவும் கூறவில்லை. உலாவி கணினி தீர்வியை, உலாவிக்குள் உள்ளமைக்கப்பட்ட தீர்வியை, அல்லது கடைசியாக இணைந்தவை தள்ளிய ஒன்றைப் பயன்படுத்தலாம். அவை ஒவ்வொன்றும் உங்கள் விதி தேர்ந்தெடுக்கும் பாதையிலிருந்து வேறுபட்ட பாதையில் வினவல்களை அனுப்பலாம், இது வழக்கமான பிளவை உருவாக்குகிறது: பக்கம் ஏற்றப்படுகிறது, பெயர் நீங்கள் எதிர்பார்க்காத இடத்தில் தீர்க்கப்படுகிறது, உள் தளம் பொது முகவரியாகத் தீர்க்கப்படுகிறது அல்லது தீர்க்கப்படவே இல்லை.
இதை வெளிப்படையாக முடிவு செய்யுங்கள். உள் பெயர்கள் சுரங்கப்பாதை வழியாகத் தீர்க்கப்பட வேண்டும் என்றால், தீர்வி அதன் உள்ளே இருக்க வேண்டும், மேலும் விதித் தொகுப்பு அந்தத் தீர்விக்கு DNS-ஐ அனுமதித்து மற்ற வினவல்களை வெளியே வைத்திருக்க வேண்டும். உலாவி பொது வழங்குநருக்கு DNS over HTTPS பயன்படுத்தினால், வினவல் உங்கள் தீர்வியை முற்றிலும் தவிர்க்கிறது, போர்ட் விதியால் உதவ முடியாது. தேர்வை ரூட்டிங் விதியின் அதே மாற்றப் பதிவில் எழுதுங்கள், ஏனெனில் அடுத்த தோல்வியைப் பிழைதிருத்துபவர் இரண்டையும் ஒன்றாகப் படிப்பார்.
பின்னர் பக்கத்துடன் அல்ல, தீர்வியுடன் சரிபார்க்கவும்:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'பதில் இல்லாதது தீர்வுப் பிரச்சினை, உலாவியின் பிழைச் செய்தி வலையமைப்பைக் குற்றம் சாட்டும்போதும். இந்த இரண்டு தோல்விகளும் பயனருக்கு ஒரே மாதிரி தெரிகின்றன, ஆனால் முற்றிலும் வேறுபட்ட டிக்கெட்டுகள்.
மூன்று எல்லைகள், மூன்று வெவ்வேறு வழிமுறைகள்
உங்களுக்கு வேண்டிய எல்லைக்குப் பெயரிட்டவுடன் பெரும்பாலான குழப்பம் மறைந்துவிடும். அவை ஒன்றுக்கொன்று மாற்றக்கூடியவை அல்ல, சுரங்கப்பாதை விழும்போது ஒவ்வொன்றுக்கும் வேறு தோல்வி முறை உள்ளது.
| What you actually want | Mechanism that fits | What it does not cover |
|---|---|---|
| These transport ports use this exit | Firewall mark plus policy route | Applications, HTTP/3 over UDP, DNS |
| This browsing session stays separate | Application-aware VPN, or a separate network namespace plus a proxy | Other applications in the same session |
| Only these private sites are reachable | Destination-based routes with private DNS | Public sites on the same address family |
தனி உலாவி சுயவிவரம் நடுப் பத்தியின் பொறி. அது குக்கிகள் மற்றும் வரலாற்றைப் பிரிக்கிறது, ஹோஸ்டின் ரூட்டிங் அட்டவணையில் எதையும் மாற்றவில்லை, எனவே இரண்டு சுயவிவரங்களும் ஒரே பாதையில் செல்கின்றன. தனிமைப்படுத்தலுக்கு கர்னல் திணிக்கும் ஒன்று தேவை, அதாவது பெயர்வெளி, கொள்கலன் அல்லது தனது சொந்த சுரங்கப்பாதை இடைமுகத்தைக் கொண்ட ஒரு பயன்பாடு.
எந்தப் பத்தி பொருந்தினாலும், சுரங்கப்பாதை விழும்போது என்ன நடக்க வேண்டும் என்பதை எழுதுங்கள். இடைமுகத்துடன் மறையும் குறி அடிப்படையிலான வழித்தடம் பொதுவாக இயற்பியல் இயல்புநிலை வழித்தடத்திற்குத் திரும்புகிறது, இது fail-open நடத்தை. இது உலாவலுக்கு ஏற்றுக்கொள்ளக்கூடியதாகவும் மற்ற எல்லாவற்றுக்கும் ஏற்றுக்கொள்ள முடியாததாகவும் இருக்கலாம், மேலும் இது ஒரு முடிவு, செயலாக்க விவரம் அல்ல.
நீங்கள் மூடுவதாகக் கூறும் ஓட்டங்களைச் சோதிக்கவும்
ஏற்புச் சோதனை நீங்கள் எழுதிய எல்லையைப் பின்பற்ற வேண்டும், வசதியான போர்ட் எண்களை அல்ல. சுரங்கப்பாதை வழியாகச் செல்ல வேண்டிய ஒரு ஓட்டம், செல்லக்கூடாத மற்றொன்று, நீங்கள் நினைக்காத போக்குவரத்தைப் பயன்படுத்தும் இன்னொன்று ஆகியவற்றைத் தேர்ந்தெடுக்கவும்:
ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'வழித்தடத் தேடல் ஒரு இலக்கு உண்மையில் எந்த இடைமுகத்தைப் பயன்படுத்துகிறது என்பதைச் சொல்கிறது, அதுவே பெரும்பாலான அறிக்கைகள் தவறாகக் கூறும் உண்மை. curl வரி பேச்சுவார்த்தை பதிப்பையும் முகவரி குடும்பத்தையும் உறுதிப்படுத்துகிறது. விதித் தொகுப்பின் கொட்டை சோதனையின்போது சேர்த்து வரம்பிட மறந்த விதியைப் பிடிக்கிறது, அப்படியே தற்காலிக குறி நிரந்தர fail-open ரூட்டிங்காக மாறுகிறது.
மூன்று வெளியீடுகளையும் நேர முத்திரையுடன் பதிவு செய்து மாற்றத்துடன் வைத்திருங்கள். பின்னர் யாராவது «VPN இன்ட்ராநெட்டை உடைத்தது» என்று தெரிவிக்கும்போது, நோக்கிய மற்றும் செயல்படுத்தப்பட்ட எல்லைகளுக்கு இடையிலான வேறுபாடு அந்தப் பதிவில் தெரியும், திருத்தம் விவாதமாக அல்ல, விதி மாற்றமாக இருக்கும்.