ஒரே பாதையை நிரூபிக்கும் இரு பியர் WireGuard சோதனையை எவ்வாறு உருவாக்குவது

இயல்புநிலை வழி, LAN முன்னொட்டு, DNS மற்றும் ஃபயர்வால் விலக்கு ஆகியவற்றைச் சுமக்கும் WireGuard சோதனை அவற்றில் எது உடைந்தது எனச் சொல்ல முடியாது. அதை இரு பியர், ஒரு முகவரி இணை மற்றும் ஒரு அனுமதிக்கப்பட்ட சேவையாகக் குறைக்கவும், தோல்விக்கு ஒளிய இடமிருக்காது. சலிப்பான அடிப்படையே நோயறிதல். அதை முதலில் உருவாக்குங்கள்; அதற்கு பதினைந்து நிமிடம் ஆகும், இல்லையேல் ஊகித்தலில் கழியும் பிற்பகலை மிச்சப்படுத்தும்.

அடிப்படை நிரூபிப்பது பலர் எதிர்பார்ப்பதை விட குறுகியது. இரு அடையாளங்கள் ஒத்துப்போகின்றன, UDP கேட்கும் துறைமுகத்தை அடைகிறது, ஒரு அனுமதிக்கப்பட்ட இலக்கு ஒரு கோரிக்கையைச் சுமக்கிறது என்பதை மட்டுமே அது நிரூபிக்கிறது. ஃபார்வர்டிங், NAT, LAN வழிகள் மற்றும் DNS பின்னர் ஒவ்வொன்றாகச் சேர்க்கப்படும் தனித்தனி அம்சங்கள்.

விசைகள், முகவரிகள் மற்றும் ஒரே எண்ட்பாயிண்ட்

ஒவ்வொரு அமைப்பிலும் ஒரு விசை இணையை உருவாக்கி, அவற்றுக்கிடையே பொது பாதிகளை மட்டும் நகர்த்துங்கள். wg genkey | tee privatekey | wg pubkey > publickey ஆவணப்படுத்தப்பட்ட ஒரு வரி கட்டளையாகும், மேலும் தனிப்பட்ட விசையை பின்னர் பாதுகாக்கக்கூடிய கோப்பில் விட்டுவிடுகிறது. உங்கள் வேறு எந்த உள்ளமைவிலும் தோன்றாத வரம்பிலிருந்து சுரங்கப்பாதை முகவரிகளைத் தேர்ந்தெடுக்கவும், எடுத்துக்காட்டாக 10.99.0.1/24 மற்றும் 10.99.0.2/24. எந்த முகவரி எந்த இயந்திரத்திற்குரியது என எழுதி வையுங்கள், ஏனெனில் ஒவ்வொரு பிந்தைய சரிபார்ப்பும் அந்த மேப்பிங்கைச் சார்ந்துள்ளது.

தனிப்பட்ட விசைகள் ஒருபோதும் பயணிக்காது. ஒரு சோதனைக்கு ஒன்றை மறுபக்கத்திற்கு நகலெடுக்க வேண்டுமானால், அந்தச் சோதனை ஏற்கனவே தவறாகிவிட்டது. இரு அமைப்புகளும் NAT பின்னால் இருக்கும்போது, குறைந்தது ஒன்றிற்கு அணுகக்கூடிய UDP துறைமுகம் தேவை, மற்றொன்று அதை நோக்கிச் சுட்டும் Endpoint ஒன்றைச் சுமக்கிறது, பொது முகவரியும் துறைமுகமும் உங்கள் குறிப்புகளில் இருக்க வேண்டும், 51820 பற்றிய உங்கள் ஊகங்களில் அல்ல.

வேறு வெளிப்புற துறைமுகத்திற்கு மேப் செய்யும் துறைமுக ஃபார்வர்டிங், Endpoint அதற்குப் பொருந்தும் வரை நன்றாக வேலை செய்யும். இங்குள்ள பொருந்தாமை பிழைகளுக்குப் பதிலாக அமைதியை உருவாக்குகிறது, எனவே கம்பியில் பிழைத்திருத்துவதற்கு முன் காகிதத்தில் சரிபார்ப்பது மதிப்புள்ளது.

wg க்கு உரிய புலங்களும் உரியாதவையும்

முக்கிய புலத் தொகுப்பு சிறியது: Interface கீழ் PrivateKey மற்றும் ListenPort, Peer கீழ் PublicKey, AllowedIPs மற்றும் Endpoint. Address மற்றும் DNS wg க்கு அல்ல, wg-quick க்கு உரியவை, அதே உள்ளமைவு வேறு கருவிக்கு மாறும் தருணத்தில் இந்த வேறுபாடு கடிக்கும்.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs ஒரே நேரத்தில் இரு வேலைகளைச் செய்கிறது. எந்த இலக்குகள் சுரங்கப்பாதைக்குள் செல்கின்றன என்பதைத் தேர்ந்தெடுக்கிறது, மேலும் வரும்போது அந்த மூல முகவரிகளைப் பயன்படுத்த பியருக்கு அனுமதி அளிக்கிறது. அதனால் மறுபக்கத்தின் கண்ணாடிப் பதிவு உங்கள் சுரங்கப்பாதை முகவரியைச் சரியாகக் குறிப்பிட வேண்டும்; தவறான பியருக்கான /32 வழித்தடச் சிக்கலாகப் படிக்கப்படுகிறது, அனுமதிச் சிக்கலைப் போல நடந்துகொள்கிறது. WireGuard விரைவு தொடக்கம் புலப் பெயர்களை ஒப்பிட விரும்பினால் அதே இரு-பியர் வடிவத்தை நிலையான சொற்களில் காட்டுகிறது.

ஐகானுக்குப் பதிலாக ஹேண்ட்ஷேக் படிப்பது

இடைமுகத்தை அதை உடையவற்றின் மூலம் மேலே கொண்டு வாருங்கள், பிறகு நிலை விளக்கு அல்ல, நிலையைப் படியுங்கள். wg show ஒவ்வொரு பியருக்கும் சமீபத்திய ஹேண்ட்ஷேக்கை பைட் கவுண்டர்களுடன் அச்சிடுகிறது, கடந்த சில நிமிடங்களில் ஹேண்ட்ஷேக் இருந்தால் விசைகள், எண்ட்பாயிண்ட் மற்றும் UDP பாதை அனைத்தும் வேலை செய்கின்றன. ஒரு திசையில் மட்டும் ஏறும் கவுண்டர் அதன் சொந்த பதிலே, அது ஒருபோதும் நடக்காத ஹேண்ட்ஷேக்கின் அதே தோல்வி அல்ல.

இரு தோல்விகளும் வெவ்வேறு விசாரணைகளைக் குறிக்கின்றன. ஹேண்ட்ஷேக் முற்றிலும் இல்லாதது விசைப் பொருந்தாமை, தவறான Endpoint, தடுக்கப்பட்ட UDP அல்லது ஹேண்ட்ஷேக்கையே வீழ்த்தும் ஃபயர்வாலைக் காட்டுகிறது. ஹேண்ட்ஷேக் வெற்றியடைந்தும் தரவு எங்கும் செல்லாதது AllowedIPs, சுரங்கப்பாதை முகவரியில் கேட்காத சேவை, அல்லது LAN க்கு துறைமுகத்தை ஏற்று சுரங்கப்பாதை இடைமுகத்திற்கு ஏற்காத ஹோஸ்ட் ஃபயர்வாலைக் காட்டுகிறது. இவை அமைப்பின் வெவ்வேறு பாதிகள், விதிகளை மாற்றத் தொடங்கும் முன் அடிப்படை அவற்றைப் பிரிக்கிறது.

ஒரு அனுமதிக்கப்பட்ட சேவையை நிரூபித்து, பிறகு எதிர்த்திசை

மற்ற பியரின் சுரங்கப்பாதை முகவரிக்கு பதிலளிக்க வேண்டிய சேவையில் கோரிக்கையை அனுப்பி, ping ஐ விட சிறந்ததைத் தேர்ந்தெடுக்கவும். இல்லாத ICMP பதில் சுரங்கப்பாதைக் குறையல்ல, ஹோஸ்ட் வடிகட்டுதலாக இருக்கலாம், எனவே அமைதியான ping எந்தத் திசையையும் நிரூபிக்காது. உங்களுக்குத் தெரிந்த திறந்த துறைமுகத்திற்கான TCP இணைப்பு, அல்லது தரவைத் திருப்பித் தரும் கோரிக்கை, நீங்கள் விளக்கக்கூடிய பதிலைத் தருகிறது.

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

அடிப்படையை மேற்கோளாக வைத்திருப்பது

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

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