கில் சுவிட்ச் எந்தவொரு டிராஃபிக் பாய்வதற்கு முன்பே VPN சேவையகத்தைத் தடுக்கிறது
கில் சுவிட்ச் எந்த நிலையைத் தடுக்கிறது: முடிவுப்புள்ளித் தேடல், வெளிப்புற வழி, திரும்பும் பாதை மற்றும் காலாவதியான இணை விலக்குகள் — ஊகங்களுக்குப் பதிலாக எண்ணிகளுடன்.
கில் சுவிட்ச்கள் மக்கள் எதிர்பாராத திசையில் தோல்வியடைகின்றன: சுரங்கப்பாதை கீழே இருக்கும்போது டிராஃபிக்கைத் தடுக்க அவை கட்டப்பட்டவை, சுரங்கப்பாதையைக் கட்டும் பாக்கெட்டுகளே டிராஃபிக். அதுதான் முழுப் பிழை. சுரங்கப்பாதை வழியாக வெளியேறாத அனைத்தையும் தூக்கி எறியும் விதித் தொகுப்பு அதை உயர்த்த வேண்டிய கைக்குலுக்கலையும் தூக்கி எறிகிறது, எனவே கிளையண்ட் சுழற்சியில் மீண்டும் முயல்கிறது, பிழை முதலில் சரிபார்க்கப்படும் நிலைக்குக் காரணமாக்கப்படுகிறது. ஃபயர்வாலை விரிவாக்கும் முன் மூன்று நிலைகளில் எது மறுக்கப்படுகிறது என்பதைக் கண்டறியுங்கள்: பெயர்த் தேடல், இணைக்கு வெளிப்புறப் பாக்கெட், அல்லது திரும்பி வரும் பதில்.
சுரங்கப்பாதையும் அதன் சொந்தப் போக்குவரத்தும் எப்படி ஒன்றையொன்று சார்ந்துள்ளன
VPN கிளையண்டை ஒரே சாக்கெட் பாதையைப் பங்கிடும் இரண்டு பிணைய நிலைகளாகப் படியுங்கள். சுரங்கப்பாதை இருப்பதற்கு முன் கிளையண்ட் இயற்பியல் அடாப்டரில் சாக்கெட் திறந்து மறையாக்கப்பட்ட சட்டகங்களை இணையின் முகவரி மற்றும் துறைமுகத்திற்கு அனுப்புகிறது. அந்தப் பரிமாற்றம் வெற்றியடைந்த பிறகே சுரங்கப்பாதை சாதனத்தை உருவாக்கி வழிகளை நிறுவுகிறது. கில் சுவிட்ச் இரண்டாம் நிலை பற்றிய கொள்கை, இரண்டிற்கும் பொருந்தும் அளவுக்கு பரந்து எழுதப்பட்டது.
இடைமுக அடிப்படையிலான விதிகள் வழக்கமான வடிவம்: இதன் வழியாக வெளியேறுவதை ஏற்றுக்கொள்ளுங்கள் tun0 அல்லது wg0, மீதமுள்ள வெளியீட்டுப் பாதையைத் தூக்கி எறியுங்கள். அந்த வடிவம் கிளையண்டின் சொந்த சேவையக இணைப்பை விலக்க முடியாது, எனவே சரியான செயலாக்கம் அந்த விலக்கை வெளிப்படையாகச் சேர்க்கிறது, கையால் விதிகள் எழுதும்போது நீங்களும் அவ்வாறே செய்கிறீர்கள். Windows மற்றும் macOS இல் ஒவ்வொரு பயன்பாட்டு விதிகளும் இடைமுகத்திற்குப் பதிலாக செயல்முறையைப் பொருத்தி இதில் ஒரு பகுதியைத் தவிர்க்கின்றன, ஆனால் சுரங்கப்பாதை இருப்பதற்கு முன் செயல்முறையும் வெளியேற வேண்டும்.
மூன்று நிலைகள், அவை நடக்கும் வரிசையில்
முதல் நிலை தீர்வு. சுயவிவரம் நேரடி முகவரிக்குப் பதிலாக புரவன் பெயரைச் சேமிக்கும்போது, எதையும் அனுப்புவதற்கு முன் கிளையண்டிற்கு DNS பதில் தேவை. DNS ஐ சுரங்கப்பாதையின் தீர்வானுக்கு திருப்பும் சுயவிவரம் ஒரு முட்டுச்சந்தை உருவாக்குகிறது: தேடல் இயக்க வேண்டிய சுரங்கப்பாதை வழியாக மட்டுமே தீர்வானை அடைய முடியும். சுரங்கப்பாதைக்கு வெளியே தீர்ப்பது, அல்லது முடிவுப்புள்ளியை முகவரியில் பின்னுவது, இந்தத் தெளிவின்மையை நீக்குகிறது.
இரண்டாம் நிலை வெளிப்புறப் பாக்கெட், அது இந்த வரிசையில் முதலில் வழிமாற்றத்தையும் பின்னர் ஃபயர்வாலையும் கடக்க வேண்டும். wireguard-tools WireGuard க்காக இதன் வழிமாற்றப் பாதியைத் தானே கையாள்கிறது: தனது பாக்கெட்டுகளைக் குறித்து, இப்போது நிறுவிய இயல்புநிலை வழியைத் தவிர்க்க ஒரு கொள்கை விதியைச் சேர்க்கிறது; wg-quick கையேடு பக்கம் அந்த விதியையும் அது பயன்படுத்தும் அட்டவணையையும் விவரிக்கிறது. அந்த வழிமாற்றத்தைக் கையால் மீண்டும் கட்டியெழுப்புங்கள், அல்லது இரண்டாவது கருவி விதிகளை மீண்டும் எழுத விடுங்கள், குறிக்கப்பட்ட பாக்கெட்டுகள் அவை உருவாக்க வேண்டிய சுரங்கப்பாதைக்கே திருப்பி அனுப்பப்படலாம்.
மூன்றாம் நிலை திரும்பும் பாதை. பதிலில்லாத கைக்குலுக்கல் வெளியேற்றத் தூக்கலுக்கான சான்று அல்ல; சேவையகத்தின் உள்வரும் விதி அல்லது பொருத்தத்தை மறந்த NAT சாதனத்துடனும் சமமாகப் பொருந்துகிறது. கிளையண்டைத் தொடுவதற்கு முன் இவற்றைப் பிரிக்கவும்.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
கிளையண்டுகள் கண்டறிந்த அறிகுறியைப் பதிவு செய்கின்றன, தோல்வியடைந்த நிலையை அல்ல, எனவே அட்டவணை பொதுவாக பதிவை விட வேகமானது.
எண்ணிகள் பதிவுகளை விட வேகமாக முடிவெடுக்கின்றன
Linux இல், nft list ruleset அல்லது iptables -vnL OUTPUT ஒவ்வொரு விதிக்கும் பாக்கெட் எண்ணியை அச்சிடுகிறது. ஒரு முறை இணைக்கவும், தோல்வியடைய விடவும், பின்னர் எண்ணிகளை மீண்டும் படிக்கவும். எண்ணி நகர்ந்த விதியே கைக்குலுக்கல் தாக்கிய விதி; எங்கும் எதுவும் நகரவில்லை என்றால், பாக்கெட் ஒருபோதும் ஃபயர்வாலை அடையவில்லை. ஒரு விதித் தொகுப்பு தனது சொந்த கைக்குலுக்கலைத் தூக்கி எறிவதை நான் பார்த்திருக்கிறேன், அதைச் சொன்னது எண்ணிகள் மட்டுமே.
ஒருபோதும் ஃபயர்வாலை அடையவில்லை என்பதை ஒருபோதும் புரவனை விட்டு வெளியேறவில்லை என்பதிலிருந்து பிரிக்க, இடைமுகத்தையே கவனியுங்கள். ip -s link show dev wlan0 அனுப்பிய பாக்கெட்டுகளைத் தெரிவிக்கிறது, மேலும் tcpdump -ni wlan0 udp port 51820 சட்டகங்களைக் காட்டுகிறது. கிளையண்ட் மீண்டும் முயலும்போது அது தட்டையாக இருந்தால், குறைபாடு netfilter க்கு மேலே உள்ளது: விடுபட்ட இணை வழி, இன்னும் இல்லாத சாதனத்தைச் சுட்டும் கொள்கை விதி, அல்லது கிளையண்ட் விழுங்கும் சாக்கெட் பிழை.
விலக்குகளை ஆவண முகவரிகளில் சோதியுங்கள், எடுத்துக்காட்டாக 203.0.113.10, ஒரு தவறு மற்றொருவரின் புரவனை ஆராய முடியாதபடி.
காலாவதியான முடிவுப்புள்ளி விலக்கம் சேவையக செயலிழப்பாகப் படிக்கப்படுகிறது
மிகவும் திசைதிருப்பும் பதிப்பு இணையின் முகவரி மாறிய பிறகு தோன்றுகிறது: இயங்கும் முகவரிச் சேவை அதை நகர்த்தியது, புரவன் மீண்டும் கட்டப்பட்டது, அல்லது உங்கள் பிணையத்தின் வெளியேற்ற முகவரி வேறுபடுகிறது. விலக்கம் இன்னும் பழைய முகவரியைக் குறிப்பிடுகிறது, எனவே புதிய முகவரிக்குச் செல்லும் பாக்கெட்டுகள் தூக்கும் விதியில் விழுகின்றன. அதே உள்ளமைவு நேற்று வேலை செய்தது, அதனால்தான் மக்கள் சேவையகத்தைப் பரிசோதிப்பதில் தொடங்குகிறார்கள்.
ஃபயர்வால் விதிக்குள் உள்ள புரவன் பெயர் உங்களைக் காக்காது. nftables இல் விதித் தொகுப்பு ஏற்றப்படும்போது பெயர் தீர்க்கப்படுகிறது, எனவே அந்தக் கணத்தில் இருந்த முகவரியை அது பின்னி, நேரடி முகவரி போலக் காலாவதியாகிறது. நிலையான தீர்வு, முடிவுப்புள்ளி மாறும்போது விலக்கைப் புதுப்பித்து அதைக் குறுகலாக வைத்திருப்பதுதான்: ஒரு இணை முகவரி, ஒரு போக்குவரத்துத் துறைமுகம். முகவரி மாற்றத்தைத் தாங்கும் அளவுக்கு அகலமான வரம்பு தொடர்பில்லாத டிராஃபிக்கையும் வெளியே அனுப்பும் அளவுக்கு அகலமானது.
கில் சுவிட்ச் சேவையக புரவனில் இயங்கும்போது
அதே சார்பு மறுமுனையிலும் உள்ளது, அங்கு அதைத் தவறவிடுவது எளிது. உங்கள் VPN சேவையகமாகச் செயல்படும் இயந்திரம் கில் சுவிட்ச் உள்ள டெஸ்க்டாப் கிளையண்டையோ, மடிக்கணினியிலிருந்து நகலெடுத்த ஃபயர்வால் சுயவிவரத்தையோ இயக்கினால், அதன் தூக்கும் விதிகள் சுரங்கப்பாதைகளை முடிக்கும் சேவைக்குப் பொருந்தும். கிளையண்டின் கைக்குலுக்கலுக்கான பதில்கள் தூக்கப்படுகின்றன, எனவே சேவையகம் ஆரோக்கியமாகத் தெரிந்தும் அதன் சுரங்கப்பாதை இடைமுகம் பயன்படுத்தப்படாமல் இருக்கும்போதும் ஒவ்வொரு கிளையண்டும் இணைக்க முடியவில்லை.
அந்தப் புரவனுக்கு தூக்குவதற்கு முன் மூன்று குறுகிய ஏற்புகள் தேவை: இயற்பியல் இடைமுகத்தில் கேட்கும் துறைமுகம், மறைகுறியாக்கப்பட்ட டிராஃபிக்கிற்கான சுரங்கப்பாதை இடைமுகம், மற்றும் சுரங்கப்பாதையிலிருந்து கிளையண்டுகள் அடைய வேண்டிய இடத்திற்கு அனுப்புதல். நிறுவப்பட்ட தொகுப்பை இதனால் படியுங்கள்: nft list ruleset, iptables -S, அல்லது pfctl -sr எதையும் மாற்றுவதற்கு முன், சேமித்த விதித் தொகுப்பு மறுதொடக்கத்தைத் தாண்டி நிலைத்திருக்கும் என்பதை நினைவில் கொள்ளுங்கள், எனவே அங்குள்ள பிழை அதை உருவாக்கிய செயல்முறையை விட நீண்ட காலம் வாழும்.
இயந்திரத்தை மூடியே வைக்கும் மீட்பு வரிசை
சுயவிவரத்திலிருந்து வெளிப்புறமாக வேலை செய்யுங்கள். கிளையண்ட் பயன்படுத்தும் இணை முகவரி மற்றும் துறைமுகத்தைப் படியுங்கள், சுரங்கப்பாதை இல்லாமல் புரவன் பெயர் தீர்க்கப்படுவதை உறுதிசெய்யுங்கள், பின்னர் இயற்பியல் அடாப்டரில் மட்டும் அந்த முகவரி மற்றும் துறைமுகத்திற்கு ஒரு விலக்கைச் சேர்க்கவும். மீண்டும் இணைந்து அனுப்பும் எண்ணியைப் பாருங்கள்; முடிந்த கைக்குலுக்கலே இரண்டாம் நிலை சரிசெய்யப்பட்டது என்பதன் சமிக்ஞை.
சோதிக்கும்போது மீதமுள்ள தூக்கும் கொள்கையை அதன் இடத்தில் விடுங்கள். தீங்கற்ற சரிபார்ப்பு என்பது தொடர்பில்லாத ஆவண முகவரிக்கு இணைப்பை முயற்சித்து அது இன்னும் நேரம் முடிந்து நிற்கிறது என்பதை உறுதிசெய்வது, இது கில் சுவிட்ச் அணைக்கப்படவில்லை என்பதைக் காட்டுகிறது. சுரங்கப்பாதை நிலையானதும் விலக்கை இறுக்குங்கள், வசதி என்பதற்காக கிளையண்ட் நிரலுக்கு நிரந்தர அனைத்து-அனுமதியை விடாதீர்கள்.
சுரங்கப்பாதை ஏறியும் பயன்பாடு தோல்வியடைந்தால், மீதமுள்ள நிலைகள் இது அல்ல: பிரிக்கப்பட்ட DNS, MTU மற்றும் ஒவ்வொரு பயன்பாட்டு வழிமாற்றம் ஒவ்வொன்றும் இணைக்கப்பட்ட சுரங்கப்பாதையையும் உடைந்த டிராஃபிக்கையும் தருகின்றன, ஒவ்வொன்றுக்கும் வேறுபட்ட முதல் சரிபார்ப்பு உள்ளது.