VPN സെർവറും ക്ലയന്റും ആയി pfSense: രണ്ട് പാതകൾ, ഒരു റൗട്ടർ

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

ഏതെങ്കിലും ക്രമീകരണം തൊടുന്നതിന് മുൻപ് രണ്ട് റോളുകൾക്കും പേരിടുക

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

ഇൻബൗണ്ട് സേവനത്തിന് ഔട്ട്ബൗണ്ട് ടണലിന്റെ വിലാസങ്ങളുമായോ ഉപകരണം റൂട്ട് ചെയ്യുന്ന ഏതെങ്കിലും സ്വകാര്യ നെറ്റ്വർക്കുമായോ ഒത്തുപോകാത്ത ഒരു ടണൽ നെറ്റ്വർക്ക് വേണം. ഒത്തുപോകൽ രണ്ട് റോളുകളിലും ഒരേസമയം ലക്ഷണങ്ങൾ ഉണ്ടാക്കുന്ന ഏക തെറ്റാണ്, കടലാസിൽ അത് പിടിക്കുന്നത് വളരെ വിലകുറഞ്ഞതാണ്. ഏതെങ്കിലും ഒരു സേവനം ക്രമീകരിക്കുന്നതിന് മുൻപ് രണ്ട് കൂട്ടങ്ങളും ഓരോ റൂട്ട് ചെയ്ത സ്വകാര്യ നെറ്റ്വർക്കും ഒരിടത്ത് താരതമ്യം ചെയ്യുക.

പങ്കിട്ട ഹാർഡ്വെയർ എന്നാൽ പങ്കിട്ട ക്രെഡൻഷ്യലുകൾ എന്നല്ല, കൂടാതെ ദൂര പ്രവേശന കൂട്ടത്തിൽ നിന്നുള്ള ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് എക്സിറ്റ് ദാതാവിനെതിരെ ഉപയോഗിക്കാനാകരുത്. വേർതിരിച്ച സാമഗ്രി റദ്ദാക്കലിനെയും മുഴുവൻ കപ്പൽവ്യൂഹത്തിന്റെ സംഭവത്തിന് പകരം പ്രാദേശിക തീരുമാനമാക്കുന്നു.

സെർവറിന്റെ മറുപടികൾ WAN പാതയിൽ നിർത്തുക

ഉപകരണം സ്വയം സൃഷ്ടിക്കുന്ന മറുപടികളാണ് അശ്രദ്ധയുള്ള സ്ഥിര റൂട്ടിന്റെ ആദ്യ ഇര. റോമിംഗ് ഉപയോക്താവിന്റെ എൻകാപ്സുലേറ്റ് ചെയ്ത പാക്കറ്റ് എത്തുമ്പോൾ, മറുപടി പ്രാദേശികമായി ഉണ്ടായ ട്രാഫിക് ആണ്, അത് ആ ഉപയോക്താവ് വന്ന ഇന്റർഫേസിലൂടെ പുറത്തുപോകണം. ഔട്ട്ബൗണ്ട് ക്ലയന്റ് അതിനെ പിടിക്കുന്ന ഒരു സ്ഥിര റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ, മറുപടി തെറ്റായ ടണലിൽ കയറുകയും സേവനം ഇപ്പോഴും ആരോഗ്യമുള്ളതായി കാണുമ്പോൾ സെഷൻ നിലയ്ക്കുകയും ചെയ്യും.

ഇത് തീർപ്പാക്കുന്ന ഒരു ചെക്ക്ബോക്സ് ഇല്ല, കാരണം ഔട്ട്ബൗണ്ട് ക്ലയന്റിന് ഏത് ട്രാഫിക് പിടിക്കാം എന്നതിനെക്കുറിച്ചാണ് തീരുമാനം. ഒന്നുകിൽ ഒരു റൂട്ടും വലിക്കരുത്, നിങ്ങൾ തിരഞ്ഞെടുത്തത് മാത്രം നയിക്കുക, അല്ലെങ്കിൽ റൂട്ടുകൾ വലിച്ച് ഉപകരണത്തിന്റെ സ്വന്തം സേവനങ്ങൾ പ്രവർത്തനക്ഷമമായി നിർത്തുന്ന ഒഴിവുകൾ ചേർക്കുക. തിരഞ്ഞെടുപ്പ് ഇൻസ്റ്റൻസിന് അടുത്ത് എഴുതുക, അല്ലെങ്കിൽ അടുത്ത വ്യക്തി മറ്റേത് അനുമാനിക്കും.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

റൂട്ടിംഗ് പട്ടിക ഏറ്റവും നീളമുള്ള പൊരുത്തം അനുസരിച്ച് വായിക്കുക, എന്തെങ്കിലും ക്രമീകരിച്ച ക്രമത്തിൽ അല്ല. ചോദ്യം എക്സിറ്റ് ഇണയുടെ വിലാസത്തിന് ഏത് എൻട്രി വിജയിക്കുന്നു, ഇൻബൗണ്ട് സേവനത്തിന്റെ മറുപടിക്ക് ഏത് എൻട്രി വിജയിക്കുന്നു എന്നതാണ്, ഈ രണ്ട് ഉത്തരങ്ങളും വ്യത്യാസപ്പെടാം.

ഔട്ട്ബൗണ്ട് ടണൽ അതിന്റെ സ്വന്തം അന്ത്യബിന്ദു തിന്നാൻ അനുവദിക്കരുത്

ഔട്ട്ബൗണ്ട് ക്ലയന്റ് ടണൽ സ്ഥാപിക്കാൻ അതിന്റെ ഇണയുടെ പൊതു വിലാസത്തിൽ എത്തണം. ആ വിലാസം തന്നെ ടണലിലേക്ക് റൂട്ട് ചെയ്യപ്പെട്ടാൽ, ക്ലയന്റ് സ്വന്തം വാലിനെ പിന്തുടരുന്നു: ഗതാഗതം ഒരിക്കലും ഉയരുന്നില്ല, അല്ലെങ്കിൽ ഉയർന്ന് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്ന നിമിഷം വീഴുന്നു. ലോഗ് റൂട്ടിംഗ് തകരാറിനേക്കാൾ പ്രാമാണീകരണ സമയപരിധി കഴിഞ്ഞതുപോലെ തോന്നുന്നു, അതുകൊണ്ടാണ് റൂട്ട് ആദ്യം പരിശോധിക്കേണ്ടത്.

ക്രെഡൻഷ്യലുകൾക്ക് മുൻപ് റൂട്ട് പരിശോധിക്കുക, ടണൽ ഉയർന്നതിന് ശേഷം വീണ്ടും, കാരണം ഒരു എൻട്രി ബൂട്ടിൽ ശരിയായിരിക്കാം, ഒരു മിനിറ്റ് കഴിഞ്ഞ് തെറ്റാകാം. ഇണയുടെ വിലാസം സാധാരണ WAN പാതയിലേക്ക് വിരൽ ചൂണ്ടണം, ഒരിക്കലും ടണൽ ഉപകരണത്തിലേക്കല്ല. ഗതാഗതം സ്ഥിരമായാൽ, താൽപ്പര്യമുള്ള ചോദ്യം കൈമാറിയ ട്രാഫിക്കിലേക്ക് നീങ്ങുന്നു, അതാണ് അടുത്ത തീരുമാനം.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

ഏത് ഉപയോക്താക്കൾക്ക് എക്സിറ്റ് ലഭിക്കണമെന്ന് തിരഞ്ഞെടുക്കുക

സ്രോതസ്സ് നയം ട്രാഫിക് ഉപകരണത്തിലേക്ക് പ്രവേശിക്കുന്ന പ്രവേശന കവാടത്തിനാണ്, അതിനാൽ ദൂര പ്രവേശന കൂട്ടമോ അതിനുള്ളിലെ ഇടുങ്ങിയ ഐഡന്റിറ്റികളോ തിരഞ്ഞെടുക്കുക. എക്സിറ്റിലേക്ക് ഒരിക്കലും അയക്കരുതാത്ത സ്വകാര്യ ലക്ഷ്യസ്ഥാനങ്ങളും മാനേജ്മെന്റ് ഒഴിവുകളും സംരക്ഷിക്കുക, ആ നിയമങ്ങൾ വിശാലമായ നിയമത്തിന് മുൻപ് വയ്ക്കുക. പിന്നീട് എക്സിറ്റ് പാതയ്ക്ക് സ്വന്തം വിവർത്തനമോ റൂട്ട് ചെയ്ത മടക്ക ക്രമീകരണമോ വേണം, മിക്ക രൂപകൽപ്പനകളിലും ഇത് കൂട്ടത്തെ മൂടുന്ന എക്സിറ്റ് ഇന്റർഫേസിലെ ഔട്ട്ബൗണ്ട് NAT എന്നാണ് അർത്ഥം. വിവർത്തനം എക്സിറ്റ് തിരഞ്ഞെടുക്കുന്നില്ല; അത് ഇതിനകം പുറത്തുപോയത് മാത്രം വീണ്ടും എഴുതുന്നു, അതിനാൽ ബന്ധമില്ലാത്ത WAN-ലെ NAT നിയമം തിരഞ്ഞെടുപ്പിൽ ഒന്നും മാറ്റുന്നില്ല.

ദൂര അറ്റം ഈ രൂപകൽപ്പനയിൽ നിന്ന് കൈമാറുന്ന ട്രാഫിക് അനുവദിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം ചില ദാതാക്കൾ അനുവദിക്കുന്നു, ചിലർ ഇല്ല. വ്യത്യാസം ബന്ധിപ്പിക്കുകയും ഒന്നും വഹിക്കാതിരിക്കുകയും ചെയ്യുന്ന ടണലായി കാണുന്നു, അതിനെ പ്രാദേശിക തകരാറായി വായിക്കാൻ എളുപ്പമാണ്. മൂന്ന് പ്രവാഹങ്ങളും വെവ്വേറെ പരീക്ഷിക്കുക, കാരണം അവ സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു, മൂന്നിൽ രണ്ട് എന്നത് പകുതി നിർമ്മിച്ച രൂപകൽപ്പനയാണ്.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

ആദ്യ കമാൻഡ് റോമിംഗ് ഉപയോക്താവിന്റെ പുറം ബന്ധമാണ്, ക്ലയന്റ് ആരംഭ ക്രമം പൂർത്തിയായി റിപ്പോർട്ട് ചെയ്യുമ്പോൾ അത് പ്രവർത്തിക്കുന്നു. രണ്ടാമത്തേത് ആ ബന്ധിപ്പിച്ച ലാപ്ടോപ്പിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുന്നു, നിങ്ങളുടെ WAN വിലാസത്തിന് പകരം എക്സിറ്റ് ദാതാവിന്റെ വിലാസം റിപ്പോർട്ട് ചെയ്യണം. മൂന്നാമത്തേത് ഉപകരണത്തിൽ കൂട്ടത്തിലെ ഒരു വിലാസത്തിൽ ബന്ധിച്ച് പ്രവർത്തിക്കുന്നു, ഒരു ദൂര ഉപയോക്താവിനെയും ഒട്ടും ഉൾപ്പെടുത്താതെ കൈമാറിയ ട്രാഫിക്കിന്റെ സ്രോതസ്സ് നയം പരീക്ഷിക്കുന്നു. പകരം അത് WAN-ൽ നിന്ന് മറുപടി നൽകിയാൽ, നയം പൊരുത്തപ്പെട്ടിട്ടില്ല, ഒരു NAT എഡിറ്റിംഗും തിരഞ്ഞെടുപ്പ് പ്രശ്നം പരിഹരിക്കുന്നില്ല.

എക്സിറ്റ് പരാജയപ്പെടുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക

പരാജയ സ്വഭാവം സംഭവിക്കുന്നതിന് മുൻപ് എഴുതുക: ഔട്ട്ബൗണ്ട് ടണൽ വീഴുമ്പോൾ ഉപയോക്താക്കൾ സാധാരണ WAN-ലേക്ക് മടങ്ങുന്നുവോ, അതോ എക്സിറ്റ് തിരികെ വരുന്നതുവരെ തടയപ്പെടുന്നുവോ? രണ്ട് ഉത്തരങ്ങളും സമർത്ഥിക്കാവുന്നതാണ്, ഉപകരണം നിങ്ങൾക്ക് പകരം തിരഞ്ഞെടുക്കില്ല. നീക്കിയ റൂട്ടോ മരിച്ച ഗേറ്റ്വേയിലേക്ക് ചൂണ്ടുന്ന നയമോ സ്വയം പൂർണ്ണ തടയൽ ഫലം ഉണ്ടാക്കുന്നില്ല. തടയൽ വേണമെങ്കിൽ, നയം അത് വ്യക്തമായി പറയണം, എക്സിറ്റ് നീക്കം ചെയ്താണ് പരിശോധിക്കേണ്ടത്, അതിനെക്കുറിച്ച് ചിന്തിച്ചല്ല. മടക്കം വേണമെങ്കിൽ, അത് ഉപയോക്താക്കൾക്ക് അറിയിക്കുക, കാരണം നിശബ്ദമായി സാധാരണ പാത എടുക്കുന്ന ട്രാഫിക് ആണ് ആരോ മൂടിയതായി കരുതിയ ട്രാഫിക്.

ക്ലയന്റ് ഇൻസ്റ്റൻസ് പ്രവർത്തനരഹിതമാക്കുക, ബന്ധിപ്പിച്ച ഉപയോക്താവ് ഇപ്പോഴും എന്തിൽ എത്തുന്നുവെന്ന് നോക്കുക, പിന്നീട് അത് വീണ്ടും ആരംഭിക്കുക. സമയപരിധി കഴിയുന്ന അഭ്യർത്ഥനയാണ് നിങ്ങൾ ആവശ്യപ്പെട്ട പൂർണ്ണ തടയൽ ഫലം; WAN വിലാസത്തോടെ മറുപടി നൽകുന്നതാണ് നിങ്ങൾ രേഖപ്പെടുത്താത്ത മടക്കം. IPv6-നും DNS-നും പരിശോധന ആവർത്തിക്കുക, കാരണം IPv4-നായി എഴുതിയ നയം AAAA ട്രാഫിക്കിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ഏത് ടണലും തള്ളുന്ന റിസോൾവർ ചോദ്യം യഥാർത്ഥത്തിൽ പുറത്തുപോകുന്നിടത്തുനിന്നാണ് മറുപടി നൽകുന്നത്.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgate-ന്റെ റൂട്ട് ചെയ്ത OpenVPN കുറിപ്പ് സ്രോതസ്സ് നയവും ഇന്റർഫേസ് അനുവദനവും ഔട്ട്ബൗണ്ട് വിവർത്തനവും എങ്ങനെ ചേരുന്നു എന്ന് കാണിക്കുന്നു, അതിന്റെ സൈറ്റിൽ നിന്ന് സൈറ്റിലേക്കുള്ള പരിധിയാണ് മുഴുവനായി പകർത്തരുതാത്ത ഭാഗം. അത് നിങ്ങളോട് പറയാത്തത് മുകളിലെ മൂന്ന് വ്യവസ്ഥകളിൽ ഏതാണ് നിങ്ങളുടെ രൂപകൽപ്പന ഇതിനകം തകർത്തത് എന്നാണ്.