OpenVPN ക്ലയന്റുകൾ പരസ്പരം കാണുന്നില്ല: subnet അല്ലെങ്കിൽ net30?
ക്ലയന്റുകൾ സെർവറിലെത്തുന്നു, പക്ഷേ പരസ്പരം എത്തുന്നില്ല. ഒരു ping കൊണ്ട് തകരാറിനെ വേർതിരിച്ച്, പിന്നീട് subnet ടോപ്പോളജി, client-to-client അല്ലെങ്കിൽ ബ്രിഡ്ജ് ചെയ്ത TAP സെഗ്മെന്റ് തിരഞ്ഞെടുക്കുക.
ബന്ധമില്ലാത്ത രണ്ട് തകരാറുകൾ ഒരേ പരാതി ഉണ്ടാക്കുന്നു. ആദ്യത്തേതിൽ ഒരു ക്ലയന്റ് ടണൽ വിലാസത്തിലൂടെപോലും മറ്റൊന്നിലേക്ക് എത്തുന്നില്ല, കാരണം വിലാസങ്ങൾ ഒരേ subnet-ൽ അല്ല അല്ലെങ്കിൽ സെർവർ സമക്ഷ പ്രവാഹം കൈമാറുന്നില്ല. രണ്ടാമത്തേതിൽ ping പ്രവർത്തിക്കുന്നു, എന്നാൽ ആപ്പിന്റെ ഉപകരണ പട്ടിക ശൂന്യമായി തുടരുന്നു, കാരണം കണ്ടെത്തൽ പാളി 3 ടണലിന് വഹിക്കാനാവാത്ത broadcast-നെ ആശ്രയിക്കുന്നു. ഒരു ping അവയെ വേർതിരിക്കുന്നു, ഓരോന്നിന്റെയും പരിഹാരം മറ്റേതിന്റെ പരിഹാരവുമായി ഒട്ടും സാമ്യമുള്ളതല്ല.
ഒരു ping പ്രശ്നത്തെ രണ്ടായി പിളർക്കുന്നു
ഒരു ക്ലയന്റിൽ നിന്ന് മറ്റേ ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിലേക്ക് ping ചെയ്യുക, അതിന്റെ പേരിലേക്കല്ല, അതിന്റെ LAN വിലാസത്തിലേക്കല്ല. അത് പരാജയപ്പെട്ടാൽ, കൈമാറ്റമോ വിലാസനിർണ്ണയമോ ആണ് പ്രശ്നം, അത് ശരിയാകുന്നതുവരെ കണ്ടെത്തൽ അപ്രസക്തമാണ്. അത് വിജയിച്ചാൽ, കൈമാറ്റം ഇതിനകം പ്രവർത്തിക്കുന്നു, ശേഷിക്കുന്ന വിടവ് broadcast അല്ലെങ്കിൽ നാമ നിർണ്ണയമാണ്.
ip addr show tun0എല്ലാറ്റിനും മുൻപ് ക്ലയന്റിന്റെ ഇന്റർഫേസ് വായിക്കുക, കാരണം നെറ്റ്മാസ്ക് ടോപ്പോളജിയെ പേരിടുന്നു. /24 അല്ലെങ്കിൽ മറ്റൊരു subnet മാസ്ക് എന്നാൽ പങ്കിട്ട പൂൾ; സമക്ഷ വിലാസത്തോടുകൂടിയ /30 എന്നാൽ പഴയ പോയിന്റ്-ടു-പോയിന്റ് ക്രമീകരണം, അവിടെ ഓരോ ക്ലയന്റിനും കൃത്യം ഒരു അയൽക്കാരൻ മാത്രം, സെർവർ.
net30 vs subnet, ക്ലയന്റ് ഭാഗത്തുനിന്ന് വായിക്കുമ്പോൾ
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30-ൽ സെർവർ ഓരോ ക്ലയന്റിനും ചെറിയ ബ്ലോക്ക് നൽകുന്നു, അതിനാൽ സെർവർ അത് കൈമാറ്റം ചെയ്യാത്തിടത്തോളം മറ്റൊരു ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിലേക്ക് റൂട്ട് ഇല്ല. subnet-ൽ മുഴുവൻ പൂളും ഒരു നെറ്റ്വർക്കാണ്, ഓരോ ക്ലയന്റിനും ഏതൊരാളെയും സംബോധിപ്പിക്കാം, സെർവർ അവയ്ക്കിടയിൽ കൈമാറ്റം ചെയ്യുന്നു. അതുകൊണ്ടാണ് ഒരു സെർവർ കോൺഫിഗറേഷൻ ആരോഗ്യകരമായി തോന്നുകയും സമക്ഷങ്ങൾക്കിടയിലുള്ള ping പരാജയപ്പെടുകയും ചെയ്യുന്നത്: ഒന്നും കേടായിട്ടില്ല, ക്ലയന്റുകൾ ഒരേ നെറ്റ്വർക്കിൽ ഇല്ല എന്നു മാത്രം. ക്ലയന്റ് പ്രവർത്തിക്കുന്ന ലിങ്കും ഉത്തരം നൽകാത്ത സമക്ഷ വിലാസവും കാണുന്നു, അത് firewall പോലെ വായിക്കപ്പെടുന്നു, എന്നാൽ യഥാർത്ഥത്തിൽ വിലാസനിർണ്ണയ ക്രമീകരണമാണ്.
നിർദ്ദേശം മാറ്റുന്നത് സെർവർ ഭാഗത്തെ തിരുത്തലും പുനരാരംഭവുമാണ്, അത് ഇതിനകം തുറന്ന സെഷനുകളിലല്ല, അടുത്ത കണക്ഷനിൽ ബാധകമാണ്. മാറ്റം വിലയിരുത്തുന്നതിന് മുൻപ് ക്ലയന്റുകൾ വീണ്ടും ബന്ധിപ്പിക്കുക. ഉപകരണം വെബ് ഇന്റർഫേസിൽ നിന്ന് കോൺഫിഗറേഷൻ വീണ്ടും സൃഷ്ടിക്കുന്നുവെങ്കിൽ, നിർദ്ദേശവും ഫയലും തീയതിയും രേഖപ്പെടുത്തുക, ഇന്റർഫേസ് ഉണ്ടെങ്കിൽ അതിലൂടെ തിരുത്തുക, കാരണം പുനർനിർമ്മാണം അടുത്ത സേവിൽ കൈകൊണ്ടുള്ള തിരുത്തൽ മായ്ക്കും.
client-to-client വേറിട്ടൊരു കവാടമാണ്
ഒരേ subnet-നുള്ളിൽപോലും client-to-client സജ്ജമല്ലെങ്കിൽ, ഒരു ക്ലയന്റിൽ നിന്ന് വന്ന് മറ്റൊന്നിനായി അയച്ച പാക്കറ്റുകൾ സെർവർ ഉപേക്ഷിക്കുന്നു. ആ കീവേഡ് സെർവറിനെ വെറും സ്വീകരിക്കുന്ന അന്ത്യബിന്ദുവിൽ നിന്ന് സമക്ഷ ട്രാഫിക്കിന്റെ കൈമാറ്റക്കാരനാക്കുന്നു. ടോപ്പോളജി ശരിയാക്കിയതിന് ശേഷം ആളുകൾ വിട്ടുപോകുന്ന രണ്ടാമത്തെ വ്യവസ്ഥ ഇതാണ്.
ഇത് broadcast-ലേക്ക് വ്യാപിക്കുന്നില്ല. ഈ ക്രമീകരണം ക്ലയന്റുകൾക്കിടയിൽ unicast കൈമാറുന്നു; അത് ടണലിനെ പങ്കിട്ട സെഗ്മെന്റാക്കുന്നില്ല, അതിന്റെ എത്ര അളവും multicast കണ്ടെത്തൽ ചോദ്യം ഓരോ സമക്ഷത്തിലും എത്തിക്കില്ല.
TUN vs TAP, ഓരോന്നിനും എന്ത് വഹിക്കാം
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap ഉപകരണം LAN-ലേക്ക് ബ്രിഡ്ജ് ചെയ്യുന്നത് ദൂരസ്ഥ ക്ലയന്റുകളെ ഓഫീസിന്റെ broadcast ഡൊമെയ്നിലാക്കുന്നു, അത് കണ്ടെത്തൽ പൂർണ്ണമായി പരിഹരിക്കുന്നു. വില TAP നടപ്പിലാക്കാത്ത പ്ലാറ്റ്ഫോമുകൾ, സെർവറിൽ ഉണ്ടായിരിക്കേണ്ട ബ്രിഡ്ജ്, ഓഫീസ് കേബിളിലെ broadcast കൊടുങ്കാറ്റ് എല്ലാ ദൂരസ്ഥ ലാപ്ടോപ്പിലും എത്തുന്ന പരാജയ ഡൊമെയ്നുമാണ്.
നാമ നിർണ്ണയം ആവശ്യമുള്ള രണ്ടോ മൂന്നോ വർക്ക്‌സ്റ്റേഷനുകൾക്ക് hosts എൻട്രിയോ unicast വിലാസമോ ബ്രിഡ്ജിനെക്കാൾ വളരെ വിലകുറഞ്ഞതാണ്. നിങ്ങൾക്ക് മാറ്റാൻ കഴിയാത്ത പ്രോട്ടോക്കോൾ പാളി 2 കണ്ടെത്തലിനെ ആശ്രയിക്കുമ്പോൾ മാത്രം TAP-ലേക്ക് നീങ്ങുക, അതിന് മുൻപല്ല.
ബ്രിഡ്ജ് ഇല്ലാത്ത ഒരേ subnet-ലെ ക്ലയന്റുകൾ
LAN ശ്രേണിയിൽ നിന്ന് വിലാസം നൽകുന്നത് ക്ലയന്റിനെ കേബിളിൽ ഇരുത്തുന്നില്ല. സെർവർ ടണലിനും ഈഥർനെറ്റിനും ഇടയിൽ റൂട്ട് ചെയ്യുന്നു, അതിനാൽ ആ വിലാസത്തിനുള്ള ARP സെർവറിന്റെ ഇന്റർഫേസിൽ നിൽക്കുന്നു, ബാക്കി LAN അത് എവിടെ താമസിക്കുന്നു എന്ന് ഒരിക്കലും അറിയില്ല.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP ആ വിടവ് അടയ്ക്കുന്നു, സെർവർ ക്ലയന്റിനുവേണ്ടി ഉത്തരം നൽകുന്നു. ശ്രേണിക്ക് parpd എൻട്രികൾ കൈകാര്യം ചെയ്യുന്നു, ക്ലയന്റുകൾ വന്നുപോകുമ്പോൾ, sysctl net.ipv4.conf.eth0.proxy_arp=1 മറ്റെവിടേക്ക് റൂട്ട് ചെയ്യുന്ന എല്ലാറ്റിനും ഉത്തരം നൽകുന്നു, അത് തിരക്കുള്ള സെഗ്മെന്റിൽ സ്വന്തം അത്ഭുതങ്ങൾ സൃഷ്ടിക്കാൻ മതിയാകും വിശാലമാണ്.
ഏത് വഴി തിരഞ്ഞെടുത്താലും, ടണലിനും കേബിളിനും ഇടയിലുള്ള NAT നീക്കം ചെയ്യുക. MASQUERADE നിയമം നിങ്ങൾ ഉത്തരം നൽകാൻ ശ്രമിക്കുന്ന വിലാസനിർണ്ണയ ചോദ്യം കൃത്യമായി മറയ്ക്കുന്നു. അത് അടുത്ത വ്യക്തിക്ക് ക്ലയന്റ് ഭാഗത്തുനിന്ന് ചിന്തിക്കാനാവാത്ത ഒരു ടോപ്പോളജിയും അവശേഷിപ്പിക്കുന്നു.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ്, സെർവറിൽ tcpdump -ni tun0 ഉപയോഗിച്ച് ഒരു ശ്രമം പിടിച്ചെടുത്ത് സമക്ഷ പാക്കറ്റ് എത്തുന്നുണ്ടോ എന്ന് സ്ഥിരീകരിക്കുക. എത്തി ഉപേക്ഷിക്കപ്പെടുന്നത് client-to-client-ലേക്ക് വിരൽ ചൂണ്ടുന്നു; ഒരിക്കലും എത്താത്തത് ടോപ്പോളജിയിലേക്കോ റൂട്ടിംഗിലേക്കോ. OpenVPN 2.6 കൈപ്പുസ്തകം രണ്ട് കീവേഡുകളും സ്വതേയുള്ള ടോപ്പോളജിയും രേഖപ്പെടുത്തുന്നു, ഫോറം പോസ്റ്റിൽ നിന്ന് ഒരു വരി പകർത്തുന്നതിന് മുൻപ് നിങ്ങളുടെ പതിപ്പുമായി ഒത്തുനോക്കുന്നത് ഉചിതമാണ്.
- tun ഇന്റർഫേസ് /30 സമക്ഷ ജോഡിക്ക് പകരം പൂൾ മാസ്ക് കാണിക്കുന്നു.
- കണ്ടെത്തൽ പരിശോധിക്കുന്നതിന് മുൻപ് മറ്റേ ടണൽ വിലാസത്തിലേക്കുള്ള നേരിട്ടുള്ള ping വിജയിക്കുന്നു.
- സമക്ഷങ്ങൾ പാക്കറ്റുകൾ കൈമാറേണ്ടിവരുമ്പോഴെല്ലാം സെർവർ കോൺഫിഗറേഷനിൽ
client-to-clientഉണ്ട്. - ആപ്പ് പരാജയപ്പെടുന്നു എന്ന് പറയുന്നതിന് പകരം നിങ്ങൾ പരിശോധിക്കുന്ന കണ്ടെത്തൽ പ്രോട്ടോക്കോൾ പേരിടുക.
- ഗ്രൂപ്പിലെ എല്ലാ ക്ലയന്റ് പ്ലാറ്റ്ഫോമും പിന്തുണയ്ക്കുന്നുവെങ്കിൽ മാത്രം TAP ഉപയോഗിക്കുക.
- ഒരേ subnet-നുള്ളിലെ എത്തിച്ചേരൽ പ്രധാനമാകുമ്പോൾ NAT ടണലിനും LAN-നും ഇടയിലുള്ള വഴിയിൽ നിന്ന് മാറ്റിനിർത്തുക.