OpenVPN ലേക്ക് കണക്ട് ചെയ്തു, പക്ഷേ ping അല്ലെങ്കിൽ SMB ഷെയർ ഇല്ലേ? മൂന്ന് ഗേറ്റുകൾ പരിശോധിക്കുക

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

ഓരോ ഗേറ്റും വ്യത്യസ്ത ലക്ഷണത്തോടെ പരാജയപ്പെടുന്നു, ആദ്യത്തേത് മാത്രമാണ് VPN സെർവറിൽ.

ഫോർവേഡിംഗ് FORWARD ചെയിനിലെ ഒരു നയമാണ്

OpenVPN ലിസണറുടെ സ്വീകാരം INPUT ൽ സംഭവിക്കുന്നു, അതിനാൽ LAN ലേക്കുള്ള ഓരോ പാക്കറ്റും വലിച്ചെറിയപ്പെട്ടാലും ടണൽ കണക്ട് ചെയ്യാം. tun0 ലേക്ക് വന്ന് LAN ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്ന ട്രാഫിക് FORWARD കടന്നുപോകുന്നു, അവിടെ സ്ഥിരസ്ഥിതി DROP നയമുള്ള ഹോസ്റ്റ് അതിനെ നിശ്ശബ്ദമായി വലിച്ചെറിയുന്നു. മറ്റെന്തെങ്കിലും തൊടുന്നതിന് മുമ്പ് sysctl ഉം ചെയിനും പരിശോധിക്കുക: sysctl net.ipv4.ip_forward കൂടാതെ iptables -L FORWARD -v -n.

നിങ്ങൾ ഉദ്ദേശിക്കുന്ന ദിശയും അതിനോട് ചേരുന്ന പ്രതികരണങ്ങളും അനുവദിക്കുക, ഉദാഹരണത്തിന് ടണൽ ഇന്റർഫേസിൽ നിന്ന് LAN ഇന്റർഫേസിലേക്കുള്ള accept നിയമവും established, related ട്രാഫിക്കിനുള്ള stateful നിയമവും. LAN മറ്റൊരു റൗട്ടറിന് പിന്നിലാണെങ്കിൽ, ആ റൗട്ടറിന് ക്ലയന്റ് പൂളിലേക്ക് തിരിച്ചുള്ള റൂട്ട് അല്ലെങ്കിൽ VPN സെർവറിൽ source NAT ആവശ്യമാണ്. കൂടുതൽ നിയമങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ് ഒരു ping കൊണ്ട് ആ പാത സ്ഥിരീകരിക്കുക, കാരണം എത്തിച്ചേരാൻ കഴിയാത്ത നിയമം ഒരിക്കലും കൗണ്ടറിൽ കാണില്ല.

SMB ന് ഒരു പോർട്ടിൽ കൂടുതൽ വേണം

ഫയൽ ഷെയറിംഗ് ഒരു TCP 445 സംഭാഷണമല്ല. കണ്ടെത്തൽ UDP 137 ഉം 138 ഉം ഉപയോഗിക്കുന്നു, പഴയ NetBIOS സെഷനുകൾ TCP 139 ഉം ആധുനിക SMB സെഷനുകൾ TCP 445 ഉം ഉപയോഗിക്കുന്നു. 445 മാത്രം തുറക്കുന്ന നിയമം, മാപ്പ് ചെയ്ത ഡ്രൈവ് പ്രവർത്തിക്കുകയും നെറ്റ്വർക്ക് ബ്രൗസിംഗ് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്ന, അല്ലെങ്കിൽ നേരെ മറിച്ചുള്ള ശല്യപ്പെടുത്തുന്ന സാഹചര്യം സൃഷ്ടിക്കുന്നു.

ടണലിലൂടെയുള്ള വലിയ കൈമാറ്റങ്ങളും തകർന്ന ഷെയർ പോലെ തോന്നുന്ന MSS പ്രശ്നങ്ങളിൽ ഇടപെടുന്നു. LAN ന്റെ പൂർണ്ണ സെഗ്മെന്റ് വലിപ്പം പ്രഖ്യാപിക്കുന്ന SYN, ടണലിന്റെ ചെറിയ MTU കാരണം വലിച്ചെറിയപ്പെടുന്നു, കൈകൊടുക്കലിന് ശേഷം കണക്ഷൻ തൂങ്ങിനിൽക്കുന്നു. ഫോർവേഡിംഗ് പാതയിൽ MSS ക്ലാംപ് ചെയ്യുന്നത്, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, ആ തരത്തിലുള്ള സ്തംഭനം ഒഴിവാക്കുന്നു. ഡയറക്ടറി ലിസ്റ്റിനു പകരം കുറച്ച് മെഗാബൈറ്റിന്റെ പകർപ്പ് കൊണ്ട് പരിശോധിക്കുക, കാരണം വലിയ കൈമാറ്റങ്ങൾ കടക്കാത്തപ്പോഴും ചെറിയ പ്രതികരണങ്ങൾ കടക്കുന്നു.

ടണൽ അഡാപ്റ്റർ ഒരു പുതിയ നെറ്റ്വർക്ക് പ്രൊഫൈലായി വരുന്നു

Windows ഓരോ അഡാപ്റ്ററും ഒരു നെറ്റ്വർക്ക് പ്രൊഫൈലിൽ തരംതിരിക്കുന്നു, പുതിയ ടണൽ അഡാപ്റ്റർ സാധാരണയായി Public ൽ എത്തുന്നു, അവിടെ ഫയൽ, പ്രിന്റർ ഷെയറിംഗ് നിയമങ്ങൾ ബ്ലോക്ക് ചെയ്തിരിക്കുന്നു. അത് ഫയൽ സെർവറിലെ ഹോസ്റ്റ് ഫയർവാളിന്റെ തീരുമാനമാണ്, VPN സെർവറിലെ റൗട്ടിംഗ് പ്രശ്നമല്ല. നയം അനുവദിക്കുന്നുവെന്ന് ഉറപ്പാക്കിയ ശേഷം ബോധപൂർവ്വം വിഭാഗം മാറ്റുക Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private ഉപയോഗിച്ച്, കാരണം വിഭാഗം ഏത് ഇൻബൗണ്ട് നിയമങ്ങൾ ബാധകമാകുമെന്നും മാറ്റുന്നു.

അതേ പ്രൊഫൈൽ TCP 445 വിജയിക്കുമ്പോൾ ping പരാജയപ്പെടുന്നത് വിശദീകരിക്കുന്നു: Public ൽ എക്കോ അഭ്യർത്ഥനകൾ സ്ഥിരസ്ഥിതിയായി വലിച്ചെറിയപ്പെടുന്നു.

പേരുകൾ റൗട്ട് ചെയ്ത ടണലിനെ സ്വയം കടക്കുന്നില്ല

NetBIOS നാമവിന്യാസവും പ്രാദേശിക കണ്ടെത്തലും റൗട്ട് ചെയ്ത ടണൽ കൊണ്ടുപോകാത്ത ബ്രോഡ്കാസ്റ്റുകളെ ആശ്രയിക്കുന്നു. അതിനാൽ സെർവറിന്റെ ചെറിയ പേര് ടൈപ്പ് ചെയ്യുന്നത് പരാജയപ്പെടുന്നു, അതിന്റെ വിലാസം പ്രവർത്തിക്കുന്നു, തിരയൽ മാത്രം കേടാകുമ്പോഴും ഷെയർ കേടായി തോന്നുന്നു. ടണൽ നൽകുന്ന റിസോൾവറിൽ സെർവറിനായി ഒരു DNS റെക്കോർഡ് ചേർക്കുക, അല്ലെങ്കിൽ ഷോർട്ട്കട്ടിൽ വിലാസം ഉപയോഗിക്കുക.

വിന്യാസം ഇപ്പോഴും WINS നെ ആശ്രയിക്കുന്നുവെങ്കിൽ, ബ്രോഡ്കാസ്റ്റ് ട്രാഫിക് വരുമെന്ന് പ്രതീക്ഷിക്കാതെ ക്ലയന്റിൽ അത് കോൺഫിഗർ ചെയ്യുക. ആദ്യം വിലാസം കൊണ്ട് പരിശോധിക്കുക, പേരിന്റെ പരാജയം ഫയർവാൾ പരാജയമായി തെറ്റിദ്ധരിക്കപ്പെടാതിരിക്കാൻ.

ഒരു സമയത്ത് ഒരു പാളി പരിശോധിച്ച് ആദ്യ പരാജയം വായിക്കുക

മുകളിലേക്ക് നീങ്ങുക: ടണൽ ഗേറ്റവേയിലേക്ക് ping ചെയ്യുക, വിലാസം കൊണ്ട് LAN ഹോസ്റ്റിലേക്ക് ping ചെയ്യുക, പിന്നീട് Test-NetConnection -ComputerName 10.8.0.5 -Port 445 കൊണ്ട് സേവനത്തിന്റെ പോർട്ട് തുറക്കുക, അതിനുശേഷം മാത്രം ഷെയറിൽ പ്രാമാണീകരിക്കുക. ആദ്യം പരാജയപ്പെടുന്ന ഘട്ടമാണ് ശരിയാക്കേണ്ട പാളി, അത് കടക്കുന്നതുവരെ തുടർന്നുള്ള ഓരോ ഘട്ടവും ശബ്ദമാണ്. പോർട്ട് അടച്ചിരിക്കെ ping പ്രതികരിക്കുന്നത് ഫയൽ സെർവറിന്റെ സ്വന്തം ഫയർവാളിനെ സൂചിപ്പിക്കുന്നു, നിശ്ശബ്ദ ping ഉണ്ടായിരുന്നിട്ടും പോർട്ട് തുറക്കുന്നത് ICMP ഫിൽട്ടറിംഗിനെ സൂചിപ്പിക്കുന്നു. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ആദ്യ പരാജയ ഘട്ടം എഴുതിവെക്കുക, കാരണം രണ്ടാം മാറ്റം ആദ്യത്തിന്റെ ഫലം മറയ്ക്കുന്നു.

VPN സെർവർ LAN ന്റെ റൗട്ടർ അല്ലെങ്കിൽ, ആ റൗട്ടറിൽ തിരിച്ചുള്ള റൂട്ട് സ്ഥിരീകരിക്കുക സെർവറിലേക്ക് കൂടുതൽ നിയമങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ്. അതില്ലാതെ അഭ്യർത്ഥനകൾ ഹോസ്റ്റിൽ എത്തുന്നു, പ്രതികരണങ്ങൾ സ്ഥിരസ്ഥിതി റൂട്ടിലൂടെ ഇന്റർനെറ്റിലേക്ക് പോകുന്നു, ഇത് ക്ലയന്റ് ഭാഗത്തുനിന്ന് കൃത്യമായി ഫയർവാൾ വലിച്ചെറിയൽ പോലെ തോന്നുന്നു.

നിങ്ങളുടെ കുറിപ്പുകളിൽ ഷെയർ അക്കൗണ്ട് VPN ലോഗിനിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുക, കാരണം വിജയകരമായ ടണൽ ഫയൽ അനുമതികളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. കാണാത്ത ഒരു നിയമം ഒഴിവാക്കാൻ SMB ഇന്റർനെറ്റിലേക്ക് തുറക്കുന്നത് പരിഹാരമല്ല.