VPN വിലാസവും LAN DHCP പാട്ടവും: ടണൽ IP ആരു നൽകുന്നു?

ക്ലയന്റ് ബന്ധിപ്പിച്ച് Wi-Fi ഐക്കണിന് പകരം അഡാപ്റ്റർ നോക്കുക. 10.80.0.14 പോലുള്ള ഒരു വിലാസം ഒരു ടണലിൽ ഇരിക്കാം, എന്നാൽ ഓഫീസ് LAN-ലെ ഒരു DHCP സെർവറും ആ പാട്ടം ഒരിക്കലും രേഖപ്പെടുത്തിയിട്ടില്ല. ഏത് പ്രക്രിയയാണ് നമ്പർ തിരഞ്ഞെടുത്തത് എന്നത് പ്രശ്നപരിശോധന എവിടെ തുടങ്ങണം എന്ന് നിർണ്ണയിക്കുന്നു.

ക്ലയന്റിൽ എല്ലാം ഒരുപോലെ കാണപ്പെടുന്നു: ഒരു IPv4 വിലാസം, ഒരു മാസ്ക്, ചിലപ്പോൾ ഒരു ഡിഫോൾട്ട് ഗേറ്റ്‌വേ. ആ വിലാസത്തിന് ആരാണ് ഉത്തരം നൽകുന്നത്, ആരാണ് അതിന്റെ രേഖ സൂക്ഷിക്കുന്നത് എന്ന് ചോദിക്കുമ്പോൾ മാത്രമാണ് വ്യത്യാസം പ്രകടമാകുന്നത്.

ക്ലയന്റ് വശത്തുനിന്ന് ടണൽ വിലാസം വായിക്കുക

ആദ്യ വരിയല്ല, മുഴുവൻ ബ്ലോക്കും വായിച്ചാൽ Windows വ്യത്യാസം കാണിക്കും. ipconfig /all അഡാപ്റ്റർ വിവരണം, ഭൗതിക വിലാസം, ഒരു DHCP വരി എന്നിവ അച്ചടിക്കുന്നു. PPP അല്ലെങ്കിൽ IKEv2 ഡയൽ-അപ്പ് അഡാപ്റ്റർ സാധാരണയായി DHCP നിഷ്ക്രിയമെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, കാരണം കണക്ഷൻ LAN സെർവറിൽനിന്ന് പാട്ടത്തിനെടുക്കുന്നതിന് പകരം ഡയലിംഗ് സമയത്ത് അതിന്റെ വിലാസം ചർച്ച ചെയ്തു. DHCP പ്രവർത്തനക്ഷമമായ ടണൽ അഡാപ്റ്റർ അസാധാരണമാണ്, പ്രത്യേകം അന്വേഷിക്കേണ്ടതാണ്.

Linux അതേ വിവരം രണ്ട് ഉപകരണങ്ങളിലായി വിഭജിക്കുന്നു. ip -4 addr show dev tun0 വിലാസവും പ്രിഫിക്സ് നീളവും നൽകുന്നു. nmcli -f IP4 connection show work മൂല്യം കണക്ഷൻ പ്രൊഫൈലിൽനിന്നോ, ലിങ്കിലെ DHCP കൈമാറ്റത്തിൽനിന്നോ, തള്ളിയ കോൺഫിഗറേഷനിൽനിന്നോ വന്നതാണോ എന്ന് വെളിപ്പെടുത്തുന്നു. WireGuard ഏറ്റവും വ്യക്തമായ കേസാണ്, കാരണം ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെടുമ്പോൾ wg-quick കോൺഫിഗ് ഫയലിലെ Address വരി പ്രയോഗിക്കുന്നു, ബന്ധിപ്പിക്കുമ്പോൾ ഒരു പിയറും ഒന്നും അനുവദിക്കുന്നില്ല.

പ്രിഫിക്സും എന്തോ പറയുന്നു. /32, അല്ലെങ്കിൽ 255.255.255.255 മാസ്ക്, ഗേറ്റ്‌വേ ഒരു ഹോസ്റ്റ് വിലാസത്തിലേക്ക് റൂട്ട് ചെയ്യാൻ പ്രതീക്ഷിക്കുന്നു എന്നർത്ഥം, അതേസമയം വീതിയേറിയ മാസ്ക് ടണലിന് പിന്നിൽ എവിടെയോ ലിങ്കിലെ ഒരു സബ്നെറ്റിനെ സൂചിപ്പിക്കുന്നു.

IKEv2 കോൺഫിഗറേഷൻ പേലോഡ് എന്താണ് വഹിക്കുന്നത്

ഈ ജോലിക്ക് IKEv2-ന് സമർപ്പിതമായ ഒരു സംവിധാനമുണ്ട്. RFC 7296, വിഭാഗം 3.15.1 ൽ വിവരിച്ചിരിക്കുന്ന കോൺഫിഗറേഷൻ പേലോഡ് INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS തുടങ്ങിയ ആട്രിബ്യൂട്ടുകളും അവയുടെ IPv6 തത്തുല്യങ്ങളും വഹിക്കുന്നു. മുൻഗണനയില്ലാത്തപ്പോൾ ക്ലയന്റ് പൂജ്യം നീളമുള്ള മൂല്യമുള്ള ആട്രിബ്യൂട്ട് അയയ്ക്കുന്നു, പ്രതികരിക്കുന്നവർ ഉപയോഗിക്കാൻ ആഗ്രഹിക്കുന്ന മൂല്യം തിരികെ നൽകുന്നു. ആ കൈമാറ്റം ഇതിനകം എൻക്രിപ്റ്റ് ചെയ്ത IKE_AUTH-നുള്ളിൽ നടക്കുന്നു, അതിനാൽ ഒരു DHCP സംപ്രേഷണവും ടണൽ കടക്കുന്നില്ല.

രണ്ട് അനന്തരഫലങ്ങൾ ഉണ്ട്. ഒന്നാമതായി, വിലാസം തിരഞ്ഞെടുക്കുന്നത് പ്രതികരിക്കുന്നവരോ അവർ സമീപിക്കുന്ന ഏതെങ്കിലും അംഗീകാര ബാക്കെൻഡോ ആണ്, അതുകൊണ്ടാണ് ഒരു പൂൾ ഗേറ്റ്‌വേയിലോ RADIUS മറുപടിയിലോ ഐഡന്റിറ്റി പ്രൊവൈഡറുടെ മാപ്പിംഗിലോ നിലനിൽക്കാൻ കഴിയുന്നത്. രണ്ടാമതായി, DNS ആട്രിബ്യൂട്ട് വിലാസ ആട്രിബ്യൂട്ടിൽനിന്ന് വേറിട്ടതാണ്. 10.80.0.14 സ്വീകരിക്കുന്നത് ഏത് റിസോൾവർ തിരിച്ചുവന്നു, അല്ലെങ്കിൽ ഒന്നും വന്നുവോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

നെറ്റ്മാസ്ക് ആട്രിബ്യൂട്ട് പ്രായോഗികമായി ഐച്ഛികമാണ്. പല വിന്യാസങ്ങളും വിലാസം മാത്രം തിരികെ നൽകി ക്ലയന്റിനെ ഹോസ്റ്റ് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യാൻ അനുവദിക്കുന്നു, അതുകൊണ്ടാണ് ഒരേ പൂൾ ഒരു ക്ലയന്റിൽ /32 ആയും മറ്റൊന്നിൽ /24 ആയും തോന്നാം.

LAN DHCP സ്കോപ്പും VPN പൂളും കൂട്ടിയിടിക്കുന്നിടത്ത്

രണ്ട് അനുവദനീയരും ഒരേ ശ്രേണിയിലേക്ക് ചൂണ്ടുമ്പോഴാണ് പ്രശ്നം തുടങ്ങുന്നത്. 10.20.30.0/24-നുള്ള DHCP സെർവർ 10.20.30.128/25-നായി ക്രമീകരിച്ച VPN പൂളിനെക്കുറിച്ച് ഒന്നും അറിയുന്നില്ല, അതിനാൽ ഗേറ്റ്‌വേ അതേ വിലാസം വിദൂര ക്ലയന്റിന് നൽകുമ്പോൾ 10.20.30.140 ഒരു പ്രിന്ററിന് പാട്ടത്തിന് നൽകുന്നത് തടയാൻ ഒന്നുമില്ല. കൂട്ടിയിടി ദിവസങ്ങളോളം നിശ്ശബ്ദമായി തുടരുന്നു, പിന്നീട് ഇടയ്ക്കിടെയുള്ള ഒരു തനിപ്പകർപ്പായി പുറത്തുവരുന്നു.

റൂട്ട് ചെയ്ത സൈറ്റ്-ടു-സൈറ്റ് രൂപകൽപ്പന നിർമ്മാണപരമായി കൂട്ടിയിടി ഒഴിവാക്കുന്നു. ശാഖയിലെ ഹോസ്റ്റ് അതിന്റെ പ്രാദേശിക DHCP സെർവർ നൽകിയ വിലാസം നിലനിർത്തുന്നു. രണ്ട് ഗേറ്റ്‌വേകളിലെയും ടണൽ ഇന്റർഫേസുകൾ സ്വന്തം ലിങ്ക് വിലാസങ്ങൾ വഹിക്കുന്നു, പാക്കറ്റുകൾ എങ്ങനെ സഞ്ചരിക്കുന്നു എന്ന് റൂട്ടിംഗ് പട്ടിക തീരുമാനിക്കുന്നു. വിദൂര ആക്സസ് ക്ലയന്റുകളുടെ വിലാസങ്ങൾ മൂന്നാമത്തെ വിഭാഗമാണ്, അവ ഗേറ്റ്‌വേയുടെ ലിങ്ക് വിലാസങ്ങളുമായി കലർത്തരുത്.

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

വിലാസം ഏത് പ്രക്രിയയുടെ ഉടമസ്ഥതയിലാണെന്ന് പരിശോധിക്കുക

സ്കോപ്പ് മാറ്റുന്നതിന് മുമ്പ് ഉടമസ്ഥത തെളിയിക്കുക. ക്ലയന്റിൽ വിലാസവും പ്രിഫിക്സും രേഖപ്പെടുത്തുക. LAN-ൽ പാട്ട ഡാറ്റാബേസിൽ തിരയുക. ഗേറ്റ്‌വേയിൽ നൽകാൻ ക്രമീകരിച്ചിട്ടുള്ള പൂളുകൾ ലിസ്റ്റ് ചെയ്യുക. പാട്ട ഫയലിൽ കണ്ടെത്തിയ വിലാസം DHCP സെർവറിന്റേതാണ്, അതായത് ടണൽ ബ്രിഡ്ജ് ചെയ്തതോ റിലേ ചെയ്തതോ ആണ്; ഗേറ്റ്‌വേ പൂളിൽ മാത്രം കണ്ടെത്തിയ വിലാസം ടണൽ എൻഡ്പോയിന്റിന്റേതാണ്.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

ഉത്തരം വ്യക്തമാകുമ്പോൾ നാല് കാര്യങ്ങൾ രേഖപ്പെടുത്തുക: ഏത് ഘടകമാണ് ക്ലയന്റ് വിലാസം അനുവദിക്കുന്നത്, അതിനായി ഏത് ശ്രേണി സംവരണം ചെയ്തിരിക്കുന്നു, തിരിച്ചുള്ള ട്രാഫിക് ആ ശ്രേണിയിൽ എങ്ങനെ എത്തുന്നു, ഏത് വിഭവങ്ങൾ അത് സ്വീകരിക്കുന്നു. ആ നാല് എൻട്രികൾ ഒരു വെർച്വൽ അഡാപ്റ്റർ വരിയെ പ്രവർത്തന വസ്തുതയാക്കി മാറ്റുന്നു.

അവിടെയുള്ളപ്പോൾ DNS ആട്രിബ്യൂട്ടിനുള്ള പരിശോധന ആവർത്തിക്കുക. വിലാസങ്ങൾ നൽകുകയും റിസോൾവർ നൽകാതിരിക്കുകയും ചെയ്യുന്ന ഒരു പൂൾ ക്ലയന്റിനെ അതിന്റെ പ്രാദേശിക DNS-ൽ വിടുന്നു, ഇത് LAN ഇതിനകം ഉപയോഗിക്കുന്ന വിലാസം നൽകുന്ന പൂളിൽനിന്ന് വ്യത്യസ്തമായ ഒരു പരാജയമാണ്.