OpenVPN-ന് പിന്നിലെ Docker, VM ട്രാഫിക്: റൂട്ടോ പുനർനമ്പറോ?

ഹോസ്റ്റ് ടണലിലൂടെ ബ്രൗസ് ചെയ്യുന്നു, അരികിലെ കണ്ടെയ്നർ ഒന്നിലും എത്തുന്നില്ല. സ്വന്തം VPN ക്ലയന്റ് ഓടുന്ന കണ്ടെയ്നറിൽ നിന്ന് പോർട്ട് പ്രസിദ്ധീകരിക്കുന്നത് അതിലും മോശമാണ്: അഭ്യർത്ഥന എത്തുന്നു, മറുപടി ഒരിക്കലും പുറത്തുപോകുന്നില്ല. രണ്ടും ഹോസ്റ്റിലെ റൂട്ടിംഗ് തീരുമാനങ്ങളാണ്, Docker വെറും ദൂതൻ മാത്രം.

ഈ രണ്ടിൽ ഏതാണെന്ന് മൂന്ന് ചോദ്യങ്ങൾ തീരുമാനിക്കുന്നു, അതിന് ഒരു മിനിറ്റോളം എടുക്കും.

ഒരേ രീതിയിൽ കാണുന്ന രണ്ട് തകരാറുകൾ

ആദ്യത്തേത് തിരിച്ചുള്ള വഴിയുടെ പ്രശ്നമാണ്. പ്രസിദ്ധീകരിച്ച പോർട്ട് കണ്ടെയ്നറിലേക്ക് വിവർത്തനം ചെയ്യുന്നു, അഭ്യർത്ഥന എത്തുന്നു, മറുപടി ഹോസ്റ്റിന്റെ സ്ഥിരസ്ഥിതി റൂട്ടിലൂടെ പോകുന്നു, അതിനെ OpenVPN ക്ലയന്റ് tun0-ലേക്ക് തിരിച്ചിരിക്കുന്നു. മറുപടി വിദൂര പങ്കാളി പ്രതീക്ഷിക്കാത്ത വിലാസത്തിൽ നിന്ന് പുറത്തുപോകുന്നു, അത് ഉപേക്ഷിക്കപ്പെടുന്നു. രണ്ടാമത്തേത് പ്രിഫിക്സ് കൂട്ടിയിടിയാണ്: Docker-ന്റെ സ്ഥിരസ്ഥിതി ബ്രിഡ്ജ് 172.17.0.0/16 കൈവശം വയ്ക്കുന്നു, കോർപ്പറേറ്റ് ടണൽ അതേ ശ്രേണി തള്ളുന്നു.

ഒന്ന് റൂട്ടിംഗ് പട്ടിക കൊണ്ട് ശരിയാക്കുന്നു, മറ്റൊന്ന് ബ്രിഡ്ജ് പുനർനമ്പർ ചെയ്ത്. ഏതാണ് ഏതെന്ന് അറിയുന്നതിന് മുമ്പ് തിരുത്തുന്നതാണ് പ്രവർത്തിക്കുന്ന കണ്ടെയ്നർ തകർക്കാനുള്ള വഴി.

മൂന്ന് ചോദ്യങ്ങളിലൂടെ തീരുമാനിക്കുക

ചോദ്യം ഒന്ന്: VPN നിർത്തുമ്പോൾ തകരാറ് മാറുന്നുണ്ടോ? ടണൽ ഓഫ് ആയിരിക്കുമ്പോൾ എല്ലാം പ്രവർത്തിക്കുന്നെങ്കിൽ തിരിച്ചുള്ള വഴി സംശയിക്കുക. ചോദ്യം രണ്ട്: ip route show table all അതേ പ്രിഫിക്സ് രണ്ടുതവണ പട്ടികപ്പെടുത്തുന്നുണ്ടോ, ഒരിക്കൽ ബ്രിഡ്ജിലും ഒരിക്കൽ tun0-ലും? അതാണ് കൂട്ടിയിടി. ചോദ്യം മൂന്ന്: ബാധിച്ച വിലാസം കണ്ടെയ്നറോ, NAT ഗസ്റ്റോ, ബ്രിഡ്ജ് ചെയ്ത ഗസ്റ്റോ?

മൂന്നാം ചോദ്യം പ്രധാനമാണ്, കാരണം ഓരോന്നിനും വ്യത്യസ്തമായ ശരിയായ പരിഹാരമുണ്ട്, കണ്ടെയ്നറിന്റെ പരിഹാരം libvirt ഗസ്റ്റിൽ പ്രയോഗിക്കുന്നത് ഒരു വൈകുന്നേരം പാഴാക്കുന്നു.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

തിരിച്ചുള്ള വഴി: ഒരു ഉറവിട വിലാസത്തിനുള്ള പട്ടിക

കണ്ടെയ്നറിന്റെ ട്രാഫിക് ഭൗതിക ഇന്റർഫേസിലൂടെ പുറത്തുപോകേണ്ടതുണ്ടെങ്കിൽ, ഹോസ്റ്റ് തന്നെ ടണൽ ഉപയോഗിക്കുമ്പോൾ, ഉറവിടാധിഷ്ഠിത റൂട്ടിംഗ് ആണ് ഏറ്റവും ചെറിയ മാറ്റം. കണ്ടെയ്നറിന്റെ വിലാസവുമായി പൊരുത്തപ്പെടുന്ന ഒരു നിയമം ചേർത്ത് അതിനെ സമർപ്പിത പട്ടികയിലേക്ക് അയയ്ക്കുക. ഹോസ്റ്റിൽ മറ്റൊന്നും നീങ്ങുന്നില്ല.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

ഉറവിടം ആ വിലാസമായ ഓരോ പാക്കറ്റും ആദ്യം പട്ടിക 10 പരിശോധിക്കുന്നു, പട്ടിക 10 അതിനെ ടണലിനു പകരം ബ്രിഡ്ജ് ഗേറ്റ്വേയിലേക്ക് അയയ്ക്കുന്നു.

ഇതുകൊണ്ട് സ്ഥിരീകരിക്കുക: ip route get 1.1.1.1 from 172.22.0.3. മറുപടിയിൽ ബ്രിഡ്ജ് ഇന്റർഫേസ് ഉണ്ടാകണം, tun0 അല്ല. ഈ രീതിയിൽ ചേർത്ത നിയമങ്ങൾ റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, അതിനാൽ അവ കണ്ടെയ്നർ സ്വന്തമാക്കുന്ന unit അല്ലെങ്കിൽ നെറ്റ്വർക്ക് ഹൂക്കിൽ ഇടുക.

അതേ മാതൃക WireGuard കണ്ടെയ്നറിനും പ്രവർത്തിക്കുന്നു, അവിടെ മറുപടി വഴിക്കും വ്യക്തമായ നിയമം വേണം.

പ്രിഫിക്സ് കൂട്ടിയിടി: ബ്രിഡ്ജ് പുനർനമ്പർ ചെയ്യുക

റൂട്ടിംഗ് പട്ടിക ഒരു പ്രിഫിക്സിനെ ഒരിടത്തേക്ക് അയയ്ക്കുന്നു. VPN 172.17.0.0/16 തള്ളുമ്പോൾ Docker-ന്റെ ബ്രിഡ്ജ് ഇതിനകം അവിടെയുണ്ടെങ്കിൽ, കുറഞ്ഞ മെട്രിക് വിജയിക്കുന്നു: Docker അതിന്റെ ബന്ധിപ്പിച്ച റൂട്ട് മെട്രിക് 0-ൽ ഇടുന്നു, തള്ളിയ റൂട്ട് 50-ൽ എത്തുന്നു. അപ്പോൾ Docker പ്രവർത്തിക്കുമ്പോൾ തന്നെ ടണൽ തകർന്നതായി തോന്നുന്നു, അല്ലെങ്കിൽ നേരെ മറിച്ച്, ഇൻസ്റ്റാളേഷൻ ക്രമം അനുസരിച്ച്. മെട്രിക്കുമായി പോരാടുന്നതിനു പകരം ബ്രിഡ്ജ് പുനർനമ്പർ ചെയ്യുക.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

മാറ്റത്തിന് ശേഷം Docker പുനരാരംഭിച്ച് പഴയ പൂൾ ഉപയോഗിച്ച് നിർമ്മിച്ച നെറ്റ്വർക്കുകൾ വീണ്ടും സൃഷ്ടിക്കുക. പകരം മെട്രിക് മാറ്റുന്നത് സംഘർഷത്തെ അടുത്ത ബൂട്ടിലേക്ക് നീക്കുന്നു മാത്രം.

VM-കൾക്ക് വീണ്ടും മറ്റൊരു മറുപടി വേണം

സ്ഥിരസ്ഥിതി NAT നെറ്റ്വർക്കിലെ libvirt ഗസ്റ്റ് ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പാരമ്പര്യമായി സ്വീകരിക്കുന്നു, ഹോസ്റ്റിന്റെ ടണൽ സ്ഥിരസ്ഥിതി റൂട്ട് കൈവശപ്പെടുത്തുമ്പോൾ പുറത്ത് എത്തുന്നത് നിർത്തുന്നു. ഗസ്റ്റിനെ ബ്രിഡ്ജ് അല്ലെങ്കിൽ macvtap ഉപകരണത്തിലേക്ക് മാറ്റുന്നത് ഭൗതിക നെറ്റ്വർക്കിൽ സ്വന്തം വഴി നൽകുന്നു. virt-manager-ൽ ഹാർഡ്വെയർ ചേർക്കുക, Network തിരഞ്ഞെടുക്കുക, ഉറവിടം macvtap ഹോസ്റ്റ് ഉപകരണത്തിലേക്ക് സജ്ജീകരിക്കുക, മാതൃകയായി virtio നിലനിർത്തുക, തുടർന്ന് പഴയ NAT ഇന്റർഫേസ് നിർജ്ജീവമാക്കുക.

macvtap ഗസ്റ്റിന് സാധാരണയായി സ്വന്തം ഹോസ്റ്റിൽ എത്താൻ കഴിയില്ല. അത് തകരാറല്ല, പ്രതീക്ഷിത സ്വഭാവമാണ്, അത് നിങ്ങൾ അവശേഷിപ്പിക്കുന്ന കുറിപ്പിൽ ഉണ്ടായിരിക്കണം.

ഹോസ്റ്റിന്റെ LAN മാത്രം വേണ്ട ഗസ്റ്റിന്, വെണ്ടറിന്റെ ക്ലയന്റിൽ കാണാത്ത സ്വിച്ച് ഉണ്ടായിരിക്കാം: Mullvad ഉപയോഗിച്ച് mullvad lan set allow libvirt-നെ തൊടാതെ പ്രാദേശിക ലഭ്യത പുനഃസ്ഥാപിക്കുന്നു. കണ്ടെയ്നർ ടണലിലൂടെ മാത്രം ലഭ്യമാകേണ്ടതുണ്ടെങ്കിൽ, പ്രസിദ്ധീകരിച്ച പോർട്ട് ടണൽ വിലാസത്തിലേക്ക് ബന്ധിക്കുക, -p 10.8.0.5:8080:8080, എല്ലാ വിലാസത്തിലും പ്രസിദ്ധീകരിക്കുന്നതിനു പകരം.