Pi-യിലെ ഹോട്ട്സ്പോട്ട് ക്ലയന്റുകൾ TUN VPN വഴി വീട്ടിലെ LAN-ൽ എത്തുന്നില്ല

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

മൂന്ന് വ്യത്യസ്ത ജോലികളുള്ള മൂന്ന് കണക്ഷനുകൾ

Linux Ethernet പാലം ലക്ഷ്യ MAC വിലാസം അനുസരിച്ച് ഫ്രെയിമുകൾ കൈമാറുന്നു. OpenVPN TUN മോഡിൽ IP പാക്കറ്റുകൾ വഹിക്കുന്നു, MAC പാളി അശേഷമില്ല, അതിനാൽ പ്രാദേശിക പാലം ചേർത്താൽ ടണൽ ഒരിക്കലും പോർട്ടായി രജിസ്റ്റർ ചെയ്യുന്നില്ല. കെർണലിന്റെ TUN/TAP രേഖകൾ ആ വിഭജനം വിശദീകരിക്കുന്നു: TAP ഉപകരണം Ethernet ഇന്റർഫേസ് പോലെ തോന്നുന്നു, TUN ഉപകരണം അങ്ങനെയല്ല. രണ്ട് പ്രാദേശിക പോർട്ടുകൾ പാലം ചെയ്ത് പിന്നീട് റൂട്ട് ചെയ്യുന്ന രൂപകൽപ്പന, ഇന്റർഫേസ് പേരുകൾ എന്തുപറഞ്ഞാലും, ഒരു റൗട്ടറാണ്.

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

മോഡവും ക്ലയന്റ് പാലത്തിന് പുറത്ത് സൂക്ഷിക്കുക. PPP കണക്ഷൻ മറ്റൊരു ലേബലുള്ള Ethernet ഉപകരണമല്ല, pppd-യുടെ രേഖപ്പെടുത്തിയ ഡിഫോൾട്ട് റൂട്ട് യുക്തി IPCP ചർച്ചകൾക്ക് ശേഷം പ്രവർത്തിക്കുന്നു, ആ ലിങ്ക് വീഴുമ്പോൾ അതിന്റെ റൂട്ട് പിൻവലിക്കുന്നു. DHCP ടെംപ്ലേറ്റ് പകർത്തി ഓരോ usb0-ഉം ppp0 എന്ന് പുനർനാമകരണം ചെയ്യുന്നത് ഗേറ്റ്വേ, മെട്രിക് അല്ലെങ്കിൽ ജീവിതചക്രം സംബന്ധിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

ഏതെങ്കിലും കോൺഫിഗർ എഡിറ്റ് ചെയ്യുന്നതിന് മുൻപ് പ്രിഫിക്സുകൾ തിരഞ്ഞെടുക്കുക

ഓവർലാപ്പിംഗ് പ്രിഫിക്സുകൾ ഫയർവാൾ നിയമങ്ങളേക്കാൾ കൂടുതൽ വൈകുന്നേരങ്ങൾ നഷ്ടപ്പെടുത്തുന്നു, കാരണം ടണൽ ആരോഗ്യകരമായിരിക്കുമ്പോഴും ഓവർലാപ്പ് റൂട്ട് അന്വേഷണം തെറ്റായ ഇന്റർഫേസിലേക്ക് അയയ്ക്കുന്നു. Pi-യിൽ ഇതിനകം ഉള്ളത് ലിസ്റ്റ് ചെയ്ത് തുടങ്ങി, ഫലം നാല് വേറിട്ട കുളങ്ങളായി വായിക്കുക.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

ആദ്യ കുളം കാരിയർ മോഡത്തിന് നൽകിയ underlay വിലാസമാണ്; അത് ക്ലയന്റഭിമുഖമായ എല്ലാ പദ്ധതിയിൽ നിന്നും പുറത്തായിരിക്കണം. രണ്ടാമത്തേത് സെർവർ തിരഞ്ഞെടുത്ത ടണൽ സബ്നെറ്റാണ്, പലപ്പോഴും അതിന്റെ സ്വന്തം സ്വകാര്യ /24 നെറ്റ്വർക്ക്. മൂന്നാമത്തേത് ഹോട്ട്സ്പോട്ട് പാലം, നാലാമത്തേത് നിങ്ങൾ എത്താൻ ആഗ്രഹിക്കുന്ന വീട്ടിലെ പ്രിഫിക്സ്. ഈ നടത്തത്തിൽ ഹോട്ട്സ്പോട്ടിന് 172.28.90.0/24 ലഭിക്കുന്നു, പാലം 172.28.90.1-ൽ, വീട്ടിലെ സേവന LAN 192.168.77.0/24 നിലനിർത്തുന്നു, ഇത് ഉപഭോക്തൃ റൗട്ടറുകൾ കൊണ്ടുവരുന്ന 192.168.1.0/24, 10.0.0.0/24 ഡിഫോൾട്ടുകളെയും 100.64.0.0/10 കാരിയർ പരിധിയെയും ഒഴിവാക്കുന്നു.

ഹോട്ട്സ്പോട്ടിന്റെ DHCP പരിധിയിൽ പാലത്തിന്റെ വിലാസം മാത്രം ഗേറ്റ്വേയായി പ്രഖ്യാപിക്കുക, മറ്റൊന്നുമല്ല. ഹോട്ട്സ്പോട്ട് ക്ലയന്റുകൾക്ക് ഒരിക്കലും ഗേറ്റ്വേയായി വീട്ടിലെ വിലാസം നൽകരുത്; ആ സെഗ്മെന്റിലേക്ക് അവർക്ക് ലിങ്ക്-പാളി പാതയില്ല.

ഓരോ ദിശയും അത് ഉടമസ്ഥതയിലുള്ള വശത്ത് റൂട്ട് ചെയ്യുക

Pi-ക്ക് ടണലിലൂടെ വീട്ടിലെ പ്രിഫിക്സിലേക്ക് ഒരു റൂട്ട് വേണം. സെർവർ മോഡിലെ സെർവറുകൾ സാധാരണയായി ആ റൂട്ട് തള്ളുന്നു, അതിനാൽ ആദ്യം ഫോർവേഡിംഗ് ഓണാണെന്നും കെർണൽ tun0-ൽ നിന്ന് വീട്ടിലെ വിലാസം പരിഹരിക്കുന്നുവെന്നും ഉറപ്പാക്കുക.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

ip route get ഇപ്പോഴും underlay ഇന്റർഫേസ് റിപ്പോർട്ട് ചെയ്യുന്നുവെങ്കിൽ അവിടെ നിർത്തുക; പാതയിൽ അപ്പുറം ഒന്നും തെറ്റായ അന്വേഷണം പരിഹരിക്കാനാവില്ല.

വീട്ടിലെ ഉപകരണങ്ങൾക്ക് 172.28.90.0/24-ലേക്ക് റൂട്ടില്ല, അതിനാൽ അവയുടെ മറുപടികൾ ഡിഫോൾട്ട് ഗേറ്റ്വേ പിന്തുടർന്ന് റൗട്ടറിൽ മരിക്കുന്നു. രണ്ട് പിന്തുണയുള്ള അറ്റകുറ്റപ്പണികളുണ്ട്. ഒന്നുകിൽ ഹോട്ട്സ്പോട്ട് പ്രിഫിക്സ് VPN സെർവറിന്റെ LAN വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ഒരു സ്റ്റാറ്റിക് റൂട്ട് വീട്ടിലെ റൗട്ടറിൽ ചേർക്കുക, അല്ലെങ്കിൽ സെർവർ തന്നെ ഗേറ്റ്വേയാകുമ്പോൾ ക്ലയന്റ് പ്രിഫിക്സ് സെർവറിന്റെ സ്വന്തം റൂട്ടിംഗ് പട്ടികയിൽ രജിസ്റ്റർ ചെയ്യുക. OpenVPN-ന്റെ മൾട്ടി-ക്ലയന്റ് മോഡിൽ ക്ലയന്റ്-നിർദ്ദിഷ്ട ഡയറക്ടറി ആ ബന്ധം വഹിക്കുന്നു: ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമത്തിൽ പേരിട്ട ഫയൽ, അതിൽ iroute 172.28.90.0 255.255.255.0 ഉം അത് സെർവർ കെർണലിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്ന ബന്ധപ്പെട്ട route വരിയും അടങ്ങിയിരിക്കുന്നു. സെർവറിൽ ഊഹിച്ച കെർണൽ റൂട്ട്, ഏത് ക്ലയന്റാണ് പ്രിഫിക്സ് ഉടമസ്ഥതയിലുള്ളതെന്ന് സെർവറിനോട് പറയുന്നതിന് തുല്യമായ പ്രസ്താവനയല്ല.

ഇത് പ്രവർത്തിക്കാൻ വീട്ടിലെ നെറ്റ്വർക്കിന്റെ DHCP സേവനം VPN സെർവറിലേക്ക് മാറ്റരുത്. ഒരു വീട്ടുമുഴുവൻ ഡിഫോൾട്ട് ഗേറ്റ്വേ മാറ്റുന്നത് ഒരു സ്വകാര്യ മടങ്ങിവരവ് റൂട്ട് ചേർക്കുന്നതിനേക്കാൾ വളരെ വലിയ മാറ്റമാണ്, അത് DNS, വിലാസ റിസർവേഷനുകൾ, പുതിയ ലീസ് അവഗണിക്കുന്ന ഓരോ ഉപകരണവും പരാജയത്തിലേക്ക് വലിച്ചിടുന്നു.

ഫയർവാൾ ഊഹിക്കാതെ ഫോർവേഡിംഗ് തുറക്കുക

ഫോർവേഡിംഗ് ഓണായിരിക്കുന്നത് പാക്കറ്റിന് കടന്നുപോകാൻ അനുമതിയുണ്ടെന്ന് അർത്ഥമാക്കുന്നില്ല. പാലത്തിൽ നിന്ന് ടണലിലേക്കുള്ള ട്രാഫിക് ഇപ്പോഴും ഫിൽട്ടർ നിയമങ്ങളിൽ തട്ടുന്നു, ഡിഫോൾട്ട്-ഡ്രോപ്പ് ഫോർവേഡിംഗ് നയം ഹോട്ട്സ്പോട്ട് ട്രാഫിക് ഉപേക്ഷിക്കുമ്പോൾ Pi-യുടെ സ്വന്തം ട്രാഫിക് പ്രവർത്തിക്കുന്നു, ഇത് മുകളിലെ വിഭജിത ലക്ഷണം കൃത്യമായി സൃഷ്ടിക്കുന്നു.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0-ൽ നിന്ന് tun0-ലേക്കുള്ള അംഗീകാര നിയമവും ബന്ധപ്പെട്ട മറുപടി ദിശയും, ഉറവിടം മാറ്റിയെഴുതാൻ കഴിയുന്ന postrouting നിയമവും തിരയുക. ചെയിൻ നയം drop ആണെങ്കിൽ ഒരു നിയമവും പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, നയം accept-ലേക്ക് തിരിക്കുന്നതിന് പകരം ഇടുങ്ങിയ അംഗീകാരങ്ങൾ ചേർത്ത് വീണ്ടും പരീക്ഷിക്കുക.

വിവർത്തനം ആവശ്യകതയല്ല, നയ തിരഞ്ഞെടുപ്പാണ്. വീട്ടിലെ LAN-ലേക്കുള്ള ഉറവിട NAT ഓരോ ഹോട്ട്സ്പോട്ട് ക്ലയന്റിനെയും Pi-യുടെ ടണൽ വിലാസം പോലെ കാണിക്കുന്നു, ഇത് വീട്ടിലെ ലോഗുകളിൽ ക്ലയന്റ് തിരിച്ചുള്ള ആരോപണം നഷ്ടപ്പെടുത്തുകയും യഥാർത്ഥ ഉറവിടം പ്രതീക്ഷിക്കുന്ന സേവനങ്ങൾ തകർക്കുകയും ചെയ്യുന്നു. NAT ഇല്ലാത്ത റൂട്ടിംഗ് ക്ലയന്റ് വിലാസങ്ങൾ ദൃശ്യമായി നിലനിർത്തുന്നു, പക്ഷേ മുകളിലെ മടങ്ങിവരവ് റൂട്ടിനെ ആശ്രയിക്കുന്നു. ഒന്ന് തിരഞ്ഞെടുത്ത് DNS, IPv6 എന്നിവയും അതേ രീതിയിൽ കൈകാര്യം ചെയ്യുക, കാരണം തകർന്ന IPv6 പാതയ്ക്കൊപ്പം പ്രവർത്തിക്കുന്ന IPv4 പാത ബ്രൗസറിൽ ഇപ്പോഴും പകുതി തകർന്നതായി വായിക്കപ്പെടുന്നു.

യാത്ര പരിശോധിച്ച്, പിന്നീട് അത് ബോധപൂർവം തകർക്കുക

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

രണ്ട് ക്യാപ്ചറുകളും ഒരുമിച്ച് വായിക്കുക. br0-ൽ പ്രത്യക്ഷപ്പെട്ട് tun0-ൽ ഒരിക്കലും കാണാത്ത അഭ്യർത്ഥനകൾ Pi ഫോർവേഡ് ചെയ്യുന്നില്ല അല്ലെങ്കിൽ റൂട്ട് മറ്റെവിടെയോ ചൂണ്ടുന്നു എന്നാണ് അർത്ഥം. tun0-ൽ മറുപടിയില്ലാത്ത അഭ്യർത്ഥനകൾ വീട്ടുവശത്ത് മടങ്ങിവരവ് റൂട്ടില്ല അല്ലെങ്കിൽ സെർവർ പാക്കറ്റ് ഫിൽട്ടർ ചെയ്തു എന്നാണ് അർത്ഥം. tun0-ൽ പ്രത്യക്ഷപ്പെട്ട് br0-ൽ വീണ്ടും കാണാത്ത മറുപടികൾ വിപരീത ഫിൽട്ടർ നിയമം ഇല്ല എന്നാണ് അർത്ഥം, അവിടെ ടണൽ തികഞ്ഞതായി തോന്നുന്നു, ക്ലയന്റ് ഇപ്പോഴും ഒന്നും കാണുന്നില്ല.

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

ഹോട്ട്സ്പോട്ട് ക്ലയന്റിന് വീട്ടിലെ പേര് പരിഹരിക്കാനും TCP സേവനം തുറക്കാനും ഒരു മോഡം വീണ്ടും ബന്ധിപ്പിക്കലിന് കുറുകെ സെഷൻ ജീവനോടെ നിലനിർത്താനും കഴിയുമ്പോൾ മാത്രം രൂപകൽപ്പന സ്വീകരിക്കുക. ഒരു അപ്ലിക്കേഷന് വീട്ടിലെ സെഗ്മെന്റിൽ Ethernet തലത്തിലുള്ള കണ്ടെത്തൽ ശരിക്കും ആവശ്യമെങ്കിൽ, പ്രാദേശിക പാലത്തെ പാലമെന്ന് വിശേഷിപ്പിച്ച് പ്രക്ഷേപണം വരുന്നത് കാത്തിരിക്കുന്നതിന് പകരം പിന്തുണയുള്ള Layer 2 രൂപകൽപ്പന തിരഞ്ഞെടുക്കുക.