WireGuard ஹேண்ட்ஷேக் வேலை செய்கிறது ஆனால் இணையம் இல்லை: பாக்கெட்டைக் கண்டறியுங்கள்
ஹேண்ட்ஷேக் விசைகள் மற்றும் அணுகலை மட்டுமே நிரூபிக்கிறது. AllowedIPs-இலிருந்து அனுப்புதல், NAT மற்றும் திரும்பும் வழி வழியாக ஒரு பாக்கெட்டைக் கண்டறிந்து அது எங்கே நிற்கிறது எனப் பாருங்கள்.
சுரங்கப்பாதை இயங்குகிறது, wg show சமீபத்திய ஹேண்ட்ஷேக்கைத் தெரிவிக்கிறது, சேவையகத்தின் சுரங்கப்பாதை முகவரிக்கு நீங்கள் ping செய்யலாம், அதற்கு அப்பால் எதுவும் பதிலளிக்கவில்லை. முதல் எண்ணம் விசைகளை மீண்டும் உருவாக்குவது அல்லது உள்ளமைவை மீண்டும் பகிர்வது. அது ஏற்கனவே வேலை செய்வதாக நிரூபிக்கப்பட்ட பாதையின் அந்தப் பகுதியை மட்டுமே மாற்றுகிறது.
முடிந்த ஹேண்ட்ஷேக் இரு தரப்பும் விசைகளில் உடன்படுகின்றன, UDP முடிவுப் புள்ளியை அடைகிறது, மற்றும் கிரிப்டோ ரூட்டிங் பாக்கெட்டை ஏற்கிறது என்று கூறுகிறது. பாக்கெட் பின்னர் சேவையகத்தை விட்டு வெளியேற முடியுமா என்பதைப் பற்றி எதுவும் கூறவில்லை.
எனவே ஊகிப்பதற்குப் பதிலாக ஒரு பாக்கெட்டைக் கண்டறியுங்கள். அது இறக்கக்கூடிய நான்கு இடங்கள் உள்ளன, ஒவ்வொன்றும் வெவ்வேறு தடத்தை விட்டுச் செல்கிறது.
ஹேண்ட்ஷேக் உண்மையில் எதை நிரூபிக்கிறது
WireGuard என்பது Noise ஹேண்ட்ஷேக்குடன் அமர்வை நிறுவி, பின்னர் ஒரு சகாவுக்காக பாக்கெட்டுகளை என்க்ரிப்ட் செய்யும் UDP நெறிமுறை. wg show சில வினாடிகளுக்கு முந்தைய ஹேண்ட்ஷேக்கையும் அதிகரிக்கும் பரிமாற்ற எண்ணிக்கையையும் காட்டும்போது, முடிவுப் புள்ளி, விசைகள் மற்றும் சகாவின் பொது விசை அனைத்தும் சரியானவை.
அது நிரூபிக்காதது: உங்கள் வாடிக்கையாளர் இணையத்தை நோக்கிய போக்குவரத்தை இடைமுகத்திற்கு அனுப்புகிறதா, சேவையகம் அதை அனுப்பத் தயாரா, அல்லது பதில் திரும்பும் வழியைக் கண்டுபிடிக்க முடியுமா என்பது. இவை கர்னல் ரூட்டிங் மற்றும் ஃபயர்வால் முடிவுகள், அவை சுரங்கப்பாதைக்கு வெளியே எடுக்கப்படுகின்றன.
சேவையகத்தின் சுரங்கப்பாதை முகவரிக்கு ping செய்வது அவ்வளவு தவறாக வழிநடத்தும் சோதனையாக இருப்பதற்குக் காரணம் அதுவே. அந்த பாக்கெட் சேவையகத்திற்கே முகவரியிடப்பட்டது, எனவே அது உள்ளூரில் முடிகிறது. அதற்கு ஒருபோதும் அனுப்புதல், ஒருபோதும் மொழிபெயர்ப்பு, ஒருபோதும் இணையத்திலிருந்து திரும்பும் வழி தேவையில்லை.
AllowedIPs என்பது ஒரு ரூட்டிங் முடிவு
வாடிக்கையாளரில் AllowedIPs இரண்டு வேலைகளைச் செய்கிறது. எந்த இலக்கு முகவரிகள் இந்த சகாவின் சுரங்கப்பாதைக்குச் செல்கின்றன என்பதைத் தீர்மானிக்கும் கிரிப்டோ விசை ரூட்டிங் அட்டவணை இது, மேலும் சகா உங்களிடமிருந்து ஏற்கும் மூல முகவரிகளின் பட்டியலும் இது. வாடிக்கையாளர் உள்ளமைவில் 10.8.0.0/24 மட்டும் இருந்தால், பொது இலக்குகள் ஒருபோதும் இடைமுகத்திற்குள் வராது, உங்கள் வழக்கமான இயல்புநிலை வழி அவற்றைச் சுரங்கப்பாதைக்கு வெளியே அழைத்துச் செல்லும். அப்போது சுரங்கப்பாதை சரியாக வேலை செய்கிறது, நீங்கள் விரும்பிய எதையும் செய்யவில்லை.
உள்ளமைவு கோப்பு சொல்வதை அல்ல, வாடிக்கையாளர் உண்மையில் எதை நிறுவியது என்பதைப் பாருங்கள்:
wg show wg0 allowed-ipsip route get 1.1.1.1
இரண்டாவது கட்டளை தீர்மானமானது. பதில் உங்கள் இயற்பியல் இடைமுகத்தையும் வழக்கமான நுழைவாயிலையும் குறிப்பிட்டால், பாக்கெட் சுரங்கப்பாதை வழியாகச் செல்லவில்லை, சேவையகப் பக்கத்தில் எந்த மாற்றமும் அதைச் சரிசெய்யாது. IPv4-க்கு 0.0.0.0/0 மற்றும் IPv6-க்கு ::/0 தனித்தனியாகச் சேர்க்கவும்; ஒரு குடும்பத்திற்கு எல்லாவற்றையும் பிடிக்கும் விதி மற்றதை அதன் அசல் பாதையிலேயே விடுகிறது, இதுவே வேலை செய்யும் IPv4 சுரங்கப்பாதைக்கும் தேங்கிய IPv6 தேடலுக்கும் பொதுவான காரணம்.
நுழைவாயிலில் பாக்கெட் எங்கே இறக்கிறது
வழி சரியாக இருந்தும் பாக்கெட் இன்னும் எங்கும் செல்லவில்லை என்றால், அது சேவையகத்தை அடைந்து அங்கேயே நிற்கிறது. நான்கு சோதனைகள் பெரும்பாலான நுழைவாயில்களை உள்ளடக்குகின்றன.
அனுப்புதல். sysctl net.ipv4.ip_forward 0 திருப்பித் தருவது உன்னதமான பதில், பல விநியோகங்கள் இன்னும் இயல்பாக 0-இல் உள்ளன. அது 1 ஆக இருக்க வேண்டும், மறுதொடக்கத்தில் மறையும் கட்டளைக்குப் பதிலாக sysctl கோப்பில் நிரந்தரமாக அமைக்கப்பட வேண்டும். IPv6 அனுப்புதல் தனி சுவிட்ச்.
வடிகட்டி கொள்கை. இயல்புநிலை drop கொள்கை கொண்ட FORWARD சங்கிலி சுரங்கப்பாதை போக்குவரத்தைத் தூக்கி எறிந்து, ஹோஸ்ட்டிற்கே செல்லும் போக்குவரத்தை அனுமதிக்கும், இது அறிகுறிகளுடன் சரியாகப் பொருந்துகிறது. சேமிக்கப்பட்ட கோப்பு அல்ல, செயலில் உள்ள விதித்தொகுப்பைப் படியுங்கள்: nft list ruleset அல்லது iptables -S.
மொழிபெயர்ப்பு அல்லது ரூட்டிங். தனிப்பட்ட சுரங்கப்பாதை முகவரிகளைப் பயன்படுத்தும் வாடிக்கையாளர்களுக்கு சேவையகத்தின் வெளியேறும் இடைமுகத்தில் மூல NAT அல்லது மேல்நிலை நெட்வொர்க் திருப்பித் தரத் தெரிந்த ரூட் செய்யப்பட்ட முன்னொட்டு தேவை. இரண்டிற்கும் இடையிலான தேர்வு முகவரித் திட்டத்தைப் பின்பற்றுகிறது. ஏற்கனவே உங்கள் முன்னொட்டைத் திருப்பி ரூட் செய்யும் நெட்வொர்க்கில் MASQUERADE சேர்ப்பது பாதிப்பில்லாதது ஆனால் அர்த்தமற்றது, வழி இல்லாத இடத்தில் அதை விட்டுவிடுவது பதில்களை ரூட் செய்ய முடியாத தனிப்பட்ட வரம்பிற்கு முகவரியிட்டதாக விடுகிறது.
திரும்பும் பாதை. ரூட் செய்யப்பட்ட வடிவமைப்புகளில், மேல்நிலை ரவுட்டருக்கு உங்கள் சேவையகத்தை நோக்கிச் சுட்டும் வழி தேவை. வழங்குநரின் நெட்வொர்க்கும் அதைத் தடுக்கலாம்: பல கிளவுட்கள் இன்ஸ்டன்ஸில் மூல மற்றும் இலக்குச் சரிபார்ப்பை இயக்குகின்றன, இது மூலம் இன்ஸ்டன்ஸின் சொந்த முகவரி அல்லாத பாக்கெட்டுகளை அமைதியாகத் தூக்கி எறியும், அந்தச் சரிபார்ப்பு முடக்கப்படும் வரை.
DNS ரூட்டிங்கிலிருந்து வேறு விதமாகத் தோல்வியடைகிறது
தெரிந்த முகவரிக்கு ஒரு பாக்கெட்டும் பெயர் தேடலும் இரண்டு தனித்தனி தோல்விகள், பிழைச் செய்திகள் எதிர் திசைகளில் தவறாக வழிநடத்துகின்றன. ping 1.1.1.1 வேலை செய்து உலாவி எதையும் ஏற்ற முடியாவிட்டால், வழி சரியானது, பெயர் தீர்வு இல்லை. ping தானே தோல்வியடைந்தால், DNS பொருத்தமற்றது, நீங்கள் முந்தைய பகுதிக்குத் திரும்பிவிட்டீர்கள்.
wg-quick உள்ளமைவின் DNS = வரியிலிருந்து ஒரு தீர்வியை அமைக்க முடியும், systemd-resolved ஒவ்வொரு இணைப்பிற்கும் அதன் சொந்த நடத்தையைக் கொண்டுள்ளது. சுரங்கப்பாதைக்குள் மட்டுமே அணுகக்கூடிய முகவரியுடன் தீர்வியை மேலெழுதும் VPN, சுரங்கப்பாதை விழும் தருணத்தில் ஒவ்வொரு தேடலையும் தோல்வியடையச் செய்யும், இது சுரங்கப்பாதையே இணையத்தை உடைப்பது போலத் தெரிகிறது.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
ஆதாரத்தை உருவாக்கும் வரிசை
முதலில் வாடிக்கையாளர் பக்கச் சோதனையை இயக்குங்கள், ஏனெனில் அது ஒரே கட்டளை மற்றும் பாதி சாத்தியங்களை நீக்குகிறது. பின்னர் சேவையகம் இணைய வெளியேற்றமாகவே வடிவமைக்கப்பட்டதா என்பதை உறுதிப்படுத்துங்கள்; தனிப்பட்ட அணுகலுக்காகக் கட்டப்பட்ட நுழைவாயில் பொது இலக்குகள் தோல்வியடையும்போது உடைந்ததல்ல.
சேவையகத்தில், வாடிக்கையாளரிடமிருந்து ping அனுப்பும்போது இடைமுகத்தைக் கவனியுங்கள்: tcpdump -ni wg0 icmp கோரிக்கையைக் காட்ட வேண்டும், tcpdump -ni eth0 icmp அது வெளியேறுவதைக் காட்ட வேண்டும், மொழிபெயர்க்கப்பட்டதோ இல்லையோ. அது முதலில் தோன்றி இரண்டாவது முறை தோன்றவே இல்லை என்றால், நிறுத்தம் சேவையகத்திலேயே உள்ளூரானது. அது வெளியேறி எந்தப் பதிலும் திரும்பவில்லை என்றால், சிக்கல் மேலே உள்ளது, அது வேறு உரையாடல்.
இறுதியாக, சரிசெய்தல் மறுதொடக்கத்தைத் தாண்டி நிலைத்திருக்கச் செய்யுங்கள். அனுப்புதல் sysctl கோப்பிற்கும், ஃபயர்வால் விதிகள் அவற்றை ஏற்றும் சேவைக்கும், வாடிக்கையாளர் வழிகள் இடைமுகத்தை உயர்த்தும் உள்ளமைவிற்கும் சொந்தமானவை, நீங்கள் மறக்கப்போகும் ஷெல்லுக்கு அல்ல. மீண்டும் இணைந்து, அதே இரண்டு சோதனைகளை மீண்டும் செய்து, எண்ணிக்கைகள் நகர்கின்றன என்பதை உறுதிப்படுத்துங்கள்.