WireGuard ക്ലൈന്റിന് OpenVPN ക്ലൈന്റിൽ എത്താൻ കഴിയുന്നില്ലേ?

രണ്ട് ടണലുകളും ബന്ധിപ്പിക്കുന്നു, ഓരോ ക്ലൈന്റും ഗേറ്റ്‌വേയിൽ എത്തുന്നു, ഒരാൾ മറ്റൊരാളുടെ വിലാസം പരീക്ഷിക്കുന്ന നിമിഷത്തിൽ പാക്കറ്റുകൾ അപ്രത്യക്ഷമാകുന്നു. രണ്ട് ഹാൻഡ്‌ഷേക്കുകളിലും ഒന്നും തെറ്റല്ല, കീകൾ വീണ്ടും പുറപ്പെടുവിച്ചാലും അത് മാറുന്നില്ല. ഗേറ്റ്‌വേ തന്റെ രണ്ട് ഇന്റർഫേസുകൾക്കിടയിൽ സാധാരണ എൻക്രിപ്റ്റ് ചെയ്യാത്ത IP പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു, അതിനാൽ പ്രോട്ടോക്കോളുകൾ പരസ്പരം മനസ്സിലാക്കേണ്ട ആവശ്യമില്ല; അവയ്ക്ക് വേണ്ടത് ഒരു ഹാൻഡ്‌ഷേക്കും നൽകാത്ത മൂന്ന് കാര്യങ്ങളാണ്. ഉത്ഭവ ക്ലൈന്റിൽ ലക്ഷ്യ കവറേജ്, ഗೇറ്റ്‌വേയിൽ സ്രോതസ്സ് ഉടമസ്ഥത, എതിർവശത്ത് മടങ്ങിവരുന്ന പാത. മൂന്നിനും ലക്ഷണം ഒന്നുതന്നെയാണ്, അതിനാൽ അവ ഒരുമിച്ച് രോഗനിർണയം ചെയ്യുന്നു.

ലക്ഷണത്തിൽ ഒരു സമയത്ത് ഒരു ഭാഗം മാത്രം കുറവാണ്

ഈ രൂപകൽപ്പന wg1 ൽ 10.71.0.0/24 ന്റെ WireGuard പൂൾ, tun1 ൽ 10.72.0.0/24 ന്റെ OpenVPN പൂൾ എന്നിവ ഉപയോഗിക്കുന്നു, രണ്ടും ഒരു ഗേറ്റ്‌വേയിൽ അവസാനിക്കുന്നു. പരീക്ഷിക്കുന്ന അഭ്യർത്ഥന 10.71.0.5 ൽ നിന്ന് 10.72.0.30 ലെ HTTPS ലേക്ക് പോകുന്നു. താഴെയുള്ള ഓരോ ഘട്ടവും ആ ഒരു പ്രവാഹത്തെക്കുറിച്ചാണ്. ഓരോ പരിശോധനയ്ക്കും വ്യത്യസ്ത പരാജയ അടയാളമുണ്ടെങ്കിലും ഉപയോക്താവ് അവ ഒരുപോലെ അനുഭവിക്കുന്നു, സാധാരണയായി ഒരു സമയത്ത് മൂന്നിൽ ഒന്ന് മാത്രമാണ് കുറവ്.

രണ്ട് പൂളുകളും യഥാർത്ഥത്തിൽ ഈ ഗേറ്റ്‌വേയിലുണ്ടെന്നും ടണലുകൾ കഴിയുന്ന namespace ൽ ഫോർവേഡിംഗ് സജീവമാണെന്നും സ്ഥിരീകരിച്ചുകൊണ്ട് തുടങ്ങുക. രണ്ട് പ്രോട്ടോക്കോളുകളും വ്യത്യസ്ത namespace-കളിൽ അവസാനിപ്പിക്കുന്ന ഗേറ്റ്‌വേ അവയ്ക്കിടയിൽ ഒന്നും ഫോർവേഡ് ചെയ്യുന്നില്ല, ഏതെങ്കിലും peer കോൺഫിഗറേഷൻ വായിക്കുന്നതിന് മുമ്പ് അത് ഒഴിവാക്കുന്നത് നല്ലതാണ്.

സ്പോക്കിന്റെ ലക്ഷ്യ കവറേജ് വിപുലീകരിക്കുക

WireGuard ക്ലൈന്റിൽ, നിലവിലുള്ള peer എൻട്രി OpenVPN ലക്ഷ്യത്തിനായി ഗേറ്റ്‌വേ തിരഞ്ഞെടുക്കണം, അതായത് ലക്ഷ്യ പ്രിഫിക്സ് ആ peer-ന്റെ അനുവദിച്ച പട്ടികയിൽ വരണം. അത് ചേർക്കുന്നത് രണ്ടാമത്തെ ടണൽ സൃഷ്ടിക്കുന്നില്ല; ആ വിലാസം തിരയുമ്പോൾ ക്ലൈന്റ് ഏത് peer തിരഞ്ഞെടുക്കുന്നു എന്നത് മാറ്റുന്നു, wg-quick ഉപയോഗിക്കുമ്പോൾ റൂട്ട് സാധാരണയായി പട്ടിക സ്വയം പിന്തുടരുന്നു.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

യഥാർത്ഥ കീയും endpoint വരികളും തൊടാതെ വയ്ക്കുക, Table = off ഉപയോഗിക്കുന്ന മാനേജർ ഈ പട്ടികയിൽ നിന്ന് ഒരു റൂട്ടും എടുക്കുന്നില്ല എന്ന് ഓർക്കുക. അത്തരം സാഹചര്യത്തിൽ അതേ പ്രിഫിക്സ് സിസ്റ്റത്തിന്റെ റൂട്ട് പട്ടികയിൽ അതിന്റെ ഉടമസ്ഥൻ ഇൻസ്റ്റാൾ ചെയ്യണം, അവിടെ ഇല്ലാത്ത റൂട്ട് ഇല്ലാത്ത അനുവദിച്ച പ്രിഫിക്സിനെപ്പോലെത്തന്നെ കാണപ്പെടുന്നു.

ഗേറ്റ്‌വേയിൽ സ്രോതസ്സ് ഉടമസ്ഥത നിലനിർത്തുക

ഈ ക്ലൈന്റിന്റെ ഗേറ്റ്‌വേയിലെ peer എൻട്രി അതേ ക്ലൈന്റിന്റെ സ്രോതസ്സ് വിലാസം കൃത്യമായി കൈവശം വയ്ക്കണം. അനുവദിച്ച വിലാസങ്ങൾ ഇരുദിശയിലും പരിശോധിക്കുന്നു: പുറത്തേക്കുള്ള ട്രാഫിക്കിന് peer തിരഞ്ഞെടുക്കുന്നു, അകത്തേക്ക് വരുന്ന പാക്കറ്റിന്റെ സ്രോതസ്സ് അത് അയച്ച peer-ന്റേതാണെന്ന് സ്ഥിരീകരിക്കുന്നു. സ്പോക്ക് ആ പൂളിൽ എത്താൻ ആഗ്രഹിക്കുന്നു എന്ന കാരണത്താൽ OpenVPN പൂൾ സ്പോക്കിന്റെ എൻട്രിയിൽ ഇടുന്നതാണ് ട്രാഫിക്കിനെ തെറ്റായ പങ്കാളിയിലേക്ക് നയിക്കുന്ന തെറ്റ്.

AllowedIPs = 10.71.0.5/32

ആ എൻട്രി റൂട്ടിംഗ് സൗകര്യമല്ല, ഉടമസ്ഥതയുടെ പ്രഖ്യാപനമായി വായിക്കുക. ക്ലൈന്റ് എത്തേണ്ട മറ്റെല്ലാം ക്ലൈന്റിന്റെ ലക്ഷ്യ പട്ടികയിൽ പെടുന്നു, ഈ peer എന്ത് അയയ്ക്കാം എന്ന ഗേറ്റ്‌വേയുടെ ധാരണയിൽ പെടുന്നില്ല.

OpenVPN വശത്തിന് മടങ്ങിവരുന്ന റൂട്ട് നൽകുക

ലക്ഷ്യത്തിന് ഇപ്പോൾ WireGuard സ്രോതസ്സിലേക്ക് തിരികെയുള്ള റൂട്ട് ആവശ്യമാണ്, പൂൾ ക്ലൈന്റുകൾക്ക് അത് സാധാരണയായി OpenVPN സെർവറിൽ നിന്ന് തള്ളിവിടുന്ന റൂട്ടായി വരുന്നു. അത് ഉണ്ടായിരിക്കേണ്ട ക്ലൈന്റുകൾക്ക് മാത്രം തള്ളിവിടുക, നിർദ്ദേശം പ്രയോഗിച്ചു എന്ന് അനുമാനിക്കുന്നതിനു പകരം ക്ലൈന്റിൽ അത് സ്വീകരിച്ചുവെന്ന് ഉറപ്പാക്കുക.

push "route 10.71.0.0 255.255.255.0"

റൂട്ട് വിതരണം അനുമതിയല്ല. ലക്ഷ്യം പൂളിൽ അല്ലാതെ മറ്റൊരു OpenVPN ക്ലൈന്റിന് പിന്നിലായിരിക്കുമ്പോൾ, ആ ക്ലൈന്റിന്റെ സ്വന്തം LAN ഉടമസ്ഥതയും ഫോർവേഡിംഗ് ആവശ്യകതകളും രൂപകൽപ്പനയിൽ ചേരുന്നു, തള്ളിവിട്ട റൂട്ട് ആദ്യ പകുതി മാത്രമാണ്. നിർദ്ദേശങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ് ആവശ്യകത ഒരു ഗ്രാഫായി വീണ്ടും എഴുതുക: ഏത് നോഡ് ഏത് പ്രിഫിക്സ് കൈവശം വയ്ക്കുന്നു, ഏത് നോഡ് അതിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു.

അനുവദിക്കാൻ ഉദ്ദേശിച്ച അതേ ഒരു സേവനം മാത്രം അനുവദിക്കുക

ഫോർവേഡിംഗ് സജീവവും രണ്ട് പൂളുകളും റൂട്ട് ചെയ്യാവുന്നതുമാകുമ്പോൾ ബാക്കിയുള്ള ചോദ്യം നയമാണ്. നിയമം പൊതുവായി ഇന്റർഫേസ് ജോടിക്കല്ല, ആ നിർദ്ദിഷ്ട പ്രവാഹത്തിന് എഴുതുക, പ്രയോഗിക്കുന്നതിന് മുമ്പ് പ്രിവ്യൂ ചെയ്യുക, മറുപടികൾ പുതിയ കണക്ഷനുകളായി തടയപ്പെടാതിരിക്കാൻ അവസ്ഥ നിലനിർത്തുന്ന മടങ്ങിവരുന്ന പാത സൂക്ഷിക്കുക. ഡ്രൈ റൺ ഒന്നും ചെലവാക്കുന്നില്ല, എന്ത് ചേർക്കുമെന്ന് കൃത്യമായി കാണിക്കുന്നു.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

ഇവ ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക്കിന്റെ നിയമങ്ങളാണ്, ഗേറ്റ്‌വേയുടെ രണ്ട് VPN സേവനങ്ങൾക്കുള്ള ശ്രവണ നിയമങ്ങളിൽ നിന്ന് വേറിട്ടത്. പുറം UDP പോർട്ടുകൾ തുറക്കുന്നത് അകത്തെ അഭ്യർത്ഥന അനുവദിക്കുന്നില്ല, അകത്തെ അഭ്യർത്ഥന അനുവദിക്കാൻ ഗേറ്റ്‌വേയിലേക്ക് പരിധിയില്ലാത്ത SSH-ഉം ഫോർവേഡിംഗിൽ സ്ഥിരസ്ഥിതി അനുമതിയും ആവശ്യമില്ല. ലക്ഷ്യത്തിന്റെ സ്വന്തം ഫയർവാളും ശ്രവണ വിലാസവും ഒത്തുപോകണം, കാരണം loopback-ൽ ബന്ധിച്ച സേവനം ഏറ്റവും സൂക്ഷ്മമായി റൂട്ട് ചെയ്ത പാക്കറ്റിനെപ്പോലും നിരസിക്കുന്നു. സംഭാഷണത്തിന്റെ ഒരു ദിശ മാത്രം ഉൾക്കൊള്ളുന്ന നയം സാധാരണയായി വിജയകരമായ അഭ്യർത്ഥനയും നിശ്ശബ്ദ മറുപടിയുമായി പരാജയപ്പെടുന്നു, ഇത് മൂന്നിൽ ഏറ്റവും ആശയക്കുഴപ്പമുള്ള ഫലമാണ്.

പരസ്പര റൂട്ടുകൾ സാധാരണയായി സ്രോതസ്സ് വിവർത്തനം ആവശ്യമില്ല എന്നാണ് അർത്ഥമാക്കുന്നത്, അത് ലക്ഷ്യത്തിൽ WireGuard വിലാസം സംരക്ഷിക്കുകയും ലോഗുകൾ വായിക്കാവുന്നതാക്കുകയും ചെയ്യുന്നു. രണ്ട് പ്രോട്ടോക്കോളുകൾ ഉൾപ്പെട്ടിരിക്കുന്നു എന്ന കാരണത്താൽ സർവവ്യാപിയായ masquerading ചേർക്കരുത്, അതിനെ ആശ്രയിക്കുന്നത് എന്തെന്ന് അറിയാതെ നിലവിലുള്ള വിവർത്തന നിയമം നീക്കരുത്. തുടർന്ന് ആ ഒരു പ്രവാഹം തുടക്കം മുതൽ അവസാനം വരെ പരിശോധിക്കുക, അനുവദിക്കാത്ത ഒരു സ്രോതസ്സോ പോർട്ടോ കൂടി പരീക്ഷിക്കുക: ഇരുവശത്തും പ്രവർത്തിക്കുന്ന ഹാൻഡ്‌ഷേക്ക് കുറുകെയുള്ള റൂട്ടോ വേർതിരിവോ തെളിയിക്കുന്നില്ല.