ഒരു NIC അല്ലെങ്കിൽ രണ്ടോ? VPN സെർവറിന്റെ ഇന്റർഫേസ് ലേഔട്ട് തീരുമാനിക്കൽ

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

അത് തീരുമാനിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ആദ്യ വ്യവസ്ഥ ലക്ഷ്യമാണ്. VPN ഹോസ്റ്റിലെ സേവനത്തിലേക്ക് ടണൽ ഇന്റർഫേസിലൂടെ മാത്രമേ എത്താനാകൂ, അതേസമയം LAN-ലുള്ള ഹോസ്റ്റിന് ഫോർവേഡിംഗും തിരിച്ചുവരവ് വഴിയും ആവശ്യമാണ്. രണ്ടാമത്തെ വ്യവസ്ഥ ആ തിരിച്ചുവരവ് വഴിയാണ്, കാരണം LAN ഉപകരണത്തിന് ക്ലയന്റ് പൂളിൽ എത്താനുള്ള വഴി അറിയണം, റൂട്ടിലൂടെയോ സെർവറിലെ വിവർത്തനത്തിലൂടെയോ.

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

ഈ മൂന്നിൽ ഒന്നും ചാസിസിലെ പോർട്ടുകളുടെ എണ്ണത്തെക്കുറിച്ചല്ല. അവ റൂട്ടിംഗ്, വിലാസങ്ങളുടെ ഉടമസ്ഥത, രൂപകൽപ്പന ഫിസിക്കൽ വേർതിരിക്കലിനെ എത്രമാത്രം ആശ്രയിക്കുന്നു എന്നിവയെക്കുറിച്ചാണ്.

ഫിസിക്കൽ സോണുകൾ, പ്രത്യേക അപ്‌ലിങ്കുകൾ, ത്രൂപുട്ട് അല്ലെങ്കിൽ ബാൻഡിന് പുറത്തുള്ള വീണ്ടെടുപ്പ് പാത ന്യായീകരിക്കുമ്പോൾ രണ്ട് അഡാപ്റ്ററുകൾ നിയമാനുസൃതമായ തിരഞ്ഞെടുപ്പായി തുടരുന്നു. അവ കൃത്യമായ ആവശ്യകതകളാണ്, ആരെങ്കിലും ഹാർഡ്വെയർ ഓർഡർ ചെയ്യുന്നതിന് മുൻപ് അവ എഴുതിവയ്ക്കുന്നത് മൂല്യവത്താണ്.

സേവനം VPN ഹോസ്റ്റിൽ പ്രവർത്തിക്കുമ്പോൾ

ഏറ്റവും ലളിതമായ കേസിൽ ഫോർവേഡിംഗ് ആവശ്യമില്ല. ഡീമൺ ടണൽ ഇന്റർഫേസിൽ ക്ലയന്റിന്റെ പാക്കറ്റുകൾ സ്വീകരിച്ച് ലോക്കൽ സോക്കറ്റിലേക്ക് നൽകുന്നു, മറുപടി അതേ ഇന്റർഫേസിലൂടെ തിരികെ വരുന്നു. ഹോസ്റ്റിന്റെ കാഴ്ചയിൽ ക്ലയന്റ് പൂളിന്റെ വിലാസം യഥാർത്ഥ ലോക്കൽ വിലാസമാണ്.

എന്നിട്ടും രണ്ട് കാര്യങ്ങൾ ശരിയായിരിക്കണം: സേവനം ടണലിന് എത്താനാകുന്ന വിലാസത്തിൽ കേൾക്കണം, ഹോസ്റ്റിന്റെ ഫയർവാൾ ടണൽ ഇന്റർഫേസിൽ എത്തുന്ന ട്രാഫിക്ക് സ്വീകരിക്കണം. രണ്ടും താഴെയുള്ള കമാൻഡുകളിൽ കാണാം.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

ലക്ഷ്യം LAN-ൽ ആയിരിക്കുമ്പോൾ

ഇവിടെയാണ് ഒറ്റ അഡാപ്റ്റർ രൂപകൽപ്പന സങ്കീർണ്ണമെന്ന പേര് നേടുന്നത്. സെർവർ ക്ലയന്റിന്റെ പാക്കറ്റുകൾ LAN-ലേക്ക് ഫോർവേഡ് ചെയ്യണം, LAN ഉപകരണം മറുപടികൾ ക്ലയന്റ് പൂളിലേക്ക് തിരികെ അയയ്ക്കണം. ആ പൂൾ LAN-ൽ ഒരു റൂട്ടായി കൊണ്ടുനടക്കുക, അല്ലെങ്കിൽ സെർവറിൽ ഉറവിട വിലാസം വിവർത്തനം ചെയ്ത് മറുപടികൾ സെർവറിലേക്കുതന്നെ തിരികെ വരുത്തുക.

രണ്ട് ഉത്തരങ്ങളും ന്യായമാണ്, അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു. തിരിച്ചുവരവ് റൂട്ട് യഥാർത്ഥ ക്ലയന്റ് വിലാസം ലക്ഷ്യത്തിന് ദൃശ്യമായി നിർത്തുന്നു, അത് ലോഗുകൾക്ക് നല്ലതും LAN വിലാസങ്ങൾ അനുമാനിക്കുന്ന ഫയർവാൾ നിയമങ്ങൾക്ക് ചീത്തയുമാണ്. വിവർത്തനം LAN-നെ ലളിതമായി നിർത്തുകയും ക്ലയന്റിന്റെ ഐഡന്റിറ്റി ലക്ഷ്യത്തിൽ നിന്ന് മറയ്ക്കുകയും ചെയ്യുന്നു.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

അസമമായ പാതയാണ് പതിവ് ലക്ഷണം: ക്ലയന്റിന്റെ അഭ്യർത്ഥന എത്തുന്നു, മറുപടി മറ്റൊരു റൂട്ടറിലൂടെ പുറത്തുപോകുന്നു, രണ്ടറ്റത്തും പിശകില്ലാതെ കണക്ഷൻ സമയം കഴിഞ്ഞ് നിലയ്ക്കുന്നു. ടണലിനെക്കുറിച്ച് എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുൻപ് ഇരുവശത്തും ക്യാപ്ചർ ചെയ്യുക.

alias രണ്ടാമതൊരു സോൺ സൃഷ്ടിക്കാത്തതെന്തുകൊണ്ട്

അതേ അഡാപ്റ്ററിൽ രണ്ടാമതൊരു വിലാസം ചേർക്കുന്നതോ, രണ്ടാം പോർട്ട് അനുകരിക്കാൻ dummy ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നതോ വളരെ കുറച്ച് മാത്രമേ മാറ്റുന്നുള്ളൂ. പാക്കറ്റുകൾ ഇപ്പോഴും അതേ ഫിസിക്കൽ ലിങ്കിലൂടെയും അതേ സ്വിച്ച് പോർട്ടിലൂടെയും സാധാരണയായി അതേ ഫയർവാൾ ചെയിനിലൂടെയും പുറത്തുപോകുന്നു, അതിനാൽ അവയ്ക്കിടയിൽ പുതിയ അതിർത്തിയുണ്ടാകുന്നില്ല. അത് കോൺഫിഗറേഷൻ സൗകര്യമാണ്, സെഗ്മെന്റേഷനല്ല. അതിനെ സോൺ അതിർത്തിയായി കാണുന്നതാണ് ഐസൊലേഷൻ അവകാശവാദം കടലാസിൽ മാത്രം അവശേഷിക്കുന്ന വഴി.

പ്രത്യേക സോണിന് പാതയിൽ യഥാർത്ഥ വേർതിരിക്കൽ വേണം, ആ ആവശ്യകതയാണ് രണ്ടാം അഡാപ്റ്റർ നിറവേറ്റുന്നത്. VPN-ലേക്കുള്ള ട്രാഫിക്ക് LAN-ലേക്കുള്ള ട്രാഫിക്കുമായി ഒരിക്കലും ബ്രോഡ്കാസ്റ്റ് ഡൊമെയ്ൻ പങ്കിടരുതെന്ന നിയമത്തെ ആശ്രയിച്ചാണ് ഒരു നിയമം എങ്കിൽ, ഹോസ്റ്റിന് എങ്ങനെ വിലാസം നൽകിയാലും ഒരു കേബിളിന് ആ ഗുണം നൽകാനാവില്ല.

ഒരു പ്രത്യേക മോഡിനായി ഉൽപ്പന്നം മൾട്ടി-ഇന്റർഫേസ് ടോപ്പോളജി രേഖപ്പെടുത്തിയിടത്ത്, പരിഹാരം കണ്ടുപിടിക്കാതെ ആ ഉൽപ്പന്നത്തിന്റെ ഡോക്യുമെന്റേഷൻ പിന്തുടരുക. വെണ്ടർമാർ റിലീസുകൾക്കിടയിൽ പിന്തുണയ്ക്കുന്ന ടോപ്പോളജികളും മാറ്റുന്നു, പഴയ വിസാർഡ് സ്ക്രീൻഷോട്ടിനെക്കാൾ നിലവിലെ ഗൈഡ് വായിക്കാൻ ഇതും ഒരു കാരണമാണ്.

നിങ്ങൾ അനുവദിക്കുന്ന ട്രാഫിക്കിനെതിരെ ലേഔട്ട് പരിശോധിക്കുക

സെർവർ വഹിക്കേണ്ട ട്രാഫിക് വിഭാഗങ്ങൾ ലിസ്റ്റ് ചെയ്യുക: ക്ലയന്റിൽ നിന്ന് ഹോസ്റ്റിലേക്ക്, ക്ലയന്റിൽ നിന്ന് LAN-ലേക്ക്, ഹോസ്റ്റിൽ നിന്ന് LAN-ലേക്ക്, എൻക്രിപ്റ്റ് ചെയ്ത പുറം കണക്ഷൻ. ഓരോ വിഭാഗത്തിനും ഉറവിടവും ലക്ഷ്യവും ഇന്റർഫേസുമുണ്ട്, ലേഔട്ട് നാലും ഒരുമിച്ച് നിറവേറ്റണം. അവയിൽ മൂന്നെണ്ണം കൈകാര്യം ചെയ്യുന്ന രൂപകൽപ്പനയാണ് സാധാരണയായി ടിക്കറ്റുകൾ ഉണ്ടാക്കുന്നത്.

തുടർന്ന് ഡിസൈൻ ഡോക്യുമെന്റിലെ ഡയഗ്രമല്ല, യഥാർത്ഥ ഇന്റർഫേസുകളും യഥാർത്ഥ ക്യാപ്ചറും സ്ഥിരീകരിക്കുക. താഴെയുള്ള കമാൻഡുകൾ രണ്ട് കാഴ്ചകളും പ്രിന്റ് ചെയ്യുന്നു.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

പുറം ക്യാപ്ചർ എൻക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക്കും ഉള്ളിലെ ക്യാപ്ചർ ടണൽ ഇന്റർഫേസിലെ ഡീക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക്കും കാണിക്കുകയും ഫിസിക്കൽ അഡാപ്റ്റർ രണ്ടും വഹിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, ഒരു NIC തന്നെ ജോലി ചെയ്യുന്നു. ഉള്ളിലെ ക്യാപ്ചർ ശൂന്യമാണെങ്കിൽ, പ്രശ്നം ടണലിലോ ഫോർവേഡിംഗ് നിയമങ്ങളിലോ ആണ്, അഡാപ്റ്ററുകളുടെ എണ്ണത്തിലല്ല. ആ രണ്ട് ക്യാപ്ചറുകളിൽ നിന്നും റൂട്ടിംഗ് ടേബിളിൽ നിന്നും ടോപ്പോളജി തീരുമാനിക്കുക, അടുത്ത മാറ്റത്തിന് താരതമ്യം ചെയ്യാൻ എന്തെങ്കിലും ഉണ്ടാകും.