ഒരു പാത മാത്രം തെളിയിക്കുന്ന രണ്ട് പിയർ 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. പരിശോധന തകർക്കുന്ന ഓരോ കൂട്ടിച്ചേർക്കലും ഇപ്പോൾ തിരിച്ചറിയാവുന്നതാണ്, കാരണം മറ്റൊന്നും നീങ്ങിയില്ല.

ഐക്കൺ പച്ചയാക്കുന്നത് മാത്രം ചെയ്യുന്ന അടിത്തറ, അടുത്ത പരാജയം ഏത് കൂട്ടിച്ചേർക്കൽ ഉണ്ടാക്കി എന്നതിനെക്കുറിച്ച് ഒന്നും പറഞ്ഞിട്ടില്ല. ഏക അനുവദിച്ച പാത റഫറൻസായി പ്രവർത്തിപ്പിച്ചു നിർത്തുക, തുടർന്നുള്ള ഓരോ മാറ്റവും അതിനെതിരെ അളക്കുന്നു.