macvlan കണ്ടെയ്നർ ഒരു VPN ക്ലയന്റിന് മറുപടി നൽകാൻ കഴിയാത്തത് എന്തുകൊണ്ട്

VPN അവസാനിപ്പിക്കുകയും അതേസമയം macvlan നെറ്റ്‌വർക്കിൽ ഒരു കണ്ടെയ്നർ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു Linux ഹോസ്റ്റ് സങ്കൽപ്പിക്കുക. LAN 192.168.60.0/24 ആണ്, കണ്ടെയ്നറിന് 192.168.60.210 ഉണ്ട്, VPN ക്ലയന്റുകൾ 10.95.0.0/24-ൽ നിന്ന് വരുന്നു. ക്ലയന്റ് സേവനത്തിലെത്തുന്നു, മറുപടി ഒരിക്കലും തിരികെ വരുന്നില്ല, ഹോസ്റ്റിലെ ഓരോ ഫയർവാൾ നിയമവും ശരിയായി തോന്നുന്നു. ഈ ലക്ഷണം രണ്ട് വെവ്വേറെ നിയന്ത്രണങ്ങൾ സൃഷ്ടിക്കുന്നു, ഒന്ന് ശരിയാക്കിയാൽ മറ്റൊന്ന് അതിന്റെ സ്ഥാനത്ത് തുടരുന്നു.

രണ്ട് നിയന്ത്രണങ്ങൾ, ഒരു ലക്ഷണം

ആദ്യ നിയന്ത്രണം ഒറ്റപ്പെടുത്തലാണ്: Docker-ന്റെ macvlan ഡ്രൈവർ കണ്ടെയ്നറിന് പാരന്റ് ഇന്റർഫേസിലൂടെ സ്വന്തം ഹോസ്റ്റുമായി സംസാരിക്കാൻ അനുവദിക്കുന്നില്ല. ഹോസ്റ്റ് സ്റ്റാക്കും കണ്ടെയ്നറും തമ്മിലുള്ള ട്രാഫിക്കിന് വഴിയില്ല, ഹോസ്റ്റിലെ റൂട്ടുകൾ എങ്ങനെ എഴുതിയാലും.

രണ്ടാമത്തെ നിയന്ത്രണം തിരിച്ചുവരവിന്റെ വഴിയാണ്. കണ്ടെയ്നറിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്‌വേ സാധാരണയായി LAN റൂട്ടർ ആണ്, അതിനാൽ VPN ക്ലയന്റിന് അയച്ച മറുപടി ആ റൂട്ടറിലൂടെ പുറത്തുപോകുന്നു. റൂട്ടറിന് VPN പൂളിലേക്ക് തിരികെയുള്ള റൂട്ട് ഇല്ലെങ്കിൽ, മറുപടി നടുവിൽ എവിടെയോ ഉപേക്ഷിക്കപ്പെടുന്നു.

ഈ രണ്ട് പരാജയങ്ങളും ക്ലയന്റിന്റെ കാഴ്ചയിൽ ഒരുപോലെ തോന്നുന്നു: എത്തുന്ന ഒരു അഭ്യർത്ഥനയും ഒരിക്കലും വരാത്ത ഒരു മറുപടിയും. അവയ്ക്ക് വ്യത്യസ്ത അറ്റകുറ്റപ്പണികൾ ആവശ്യമാണ്, വിശാലമായ masquerade നിയമത്തിന് ഏതാണ് ഇപ്പോഴും കേടായതെന്ന് മറയ്ക്കാനാകും. അതുകൊണ്ടാണ് ആദ്യ പരിശോധന മറ്റൊരു ഫയർവാൾ മാറ്റമല്ല, കണ്ടെയ്നർ വശത്തുള്ള ക്യാപ്ചർ. അഭ്യർത്ഥന അവിടെ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ലെങ്കിൽ, ഒറ്റപ്പെടുത്തൽ നിയന്ത്രണമാണ് പ്രവർത്തിക്കുന്നത്.

ഹോസ്റ്റ് വശത്തെ shim ഇടുങ്ങിയതായി നിർമ്മിക്കുക

അതേ പാരന്റിലേക്ക് ബ്രിഡ്ജ് മോഡിൽ ഘടിപ്പിച്ച രണ്ടാമത്തെ macvlan ഇന്റർഫേസ് ഹോസ്റ്റ് സ്റ്റാക്കിന് ആ LAN സെഗ്മെന്റിൽ സ്വന്തം ഐഡന്റിറ്റി നൽകുന്നു. അതിനായി DHCP പൂളിന് പുറത്തും കണ്ടെയ്നർ പരിധിക്ക് പുറത്തും ഒരു വിലാസം മാറ്റിവയ്ക്കുക, കണ്ടെയ്നർ മാത്രം അതിലൂടെ കടത്തിവിടുക.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

ആദ്യ കമാൻഡ് ഇന്റർഫേസ് ബ്രിഡ്ജ് മോഡിൽ സൃഷ്ടിക്കുന്നു, ഇത് ഈ ഡ്രൈവറിനുള്ള രേഖപ്പെടുത്തിയ ഡിഫോൾട്ടും ഹോസ്റ്റ്-കണ്ടെയ്നർ ട്രാഫിക്കിന് ആവശ്യമുള്ള മോഡുമാണ്. രണ്ടാമത്തേത് /32 നൽകുന്നു, വിലാസം LAN പ്രിഫിക്സുമായി കൂട്ടിമുട്ടാതിരിക്കാൻ, നാലാമത്തേത് shim വഴി കണ്ടെയ്നറിന്റെ വിലാസം മാത്രം അയയ്ക്കുന്നു.

പുതിയ ഇന്റർഫേസിലൂടെ മുഴുവൻ LAN-ഉം റീഡയറക്ട് ചെയ്യരുത്. സാധാരണ കണക്റ്റഡ് റൂട്ട് അതേപടി നിൽക്കുന്നു, ഹോസ്റ്റ് റൂട്ട് ബോധപൂർവം ഇടുങ്ങിയതാണ്, ഒരു കണ്ടെയ്നറിന് വഴി ലഭിക്കും, സെഗ്മെന്റിന്റെ ബാക്കി ഭാഗം അതിന്റെ സ്വഭാവം മാറ്റില്ല. shim-ലേക്ക് ചൂണ്ടുന്ന ഡിഫോൾട്ട് റൂട്ട് വ്യത്യസ്ത പരിണിതഫലങ്ങളുള്ള വ്യത്യസ്ത രൂപകൽപ്പനയായിരിക്കും. അത് കൃത്യമായി നിലനിർത്തുക, കേടുപാടിന്റെ പരിധി ചെറുതായി തുടരും.

ഈ കമാൻഡുകൾ പ്രവർത്തിക്കുന്ന ഹോസ്റ്റിലെ നെറ്റ്‌വർക്ക് ക്രമീകരണങ്ങൾ മാറ്റുന്നു. ഉപകരണത്തിലോ നിയന്ത്രിത പ്ലാറ്റ്ഫോമിലോ ആ പ്ലാറ്റ്ഫോം പിന്തുണയ്ക്കുന്ന കോൺഫിഗറേഷൻ സംവിധാനം ഉപയോഗിക്കുക, കാരണം root-shell-ൽ ചെയ്യുന്ന ഇന്ററാക്ടീവ് മാറ്റം അപ്‌ഗ്രേഡിന് ശേഷം നിലനിൽക്കണമെന്നില്ല.

സ്രോതസ്സ് എങ്ങനെ സംരക്ഷിക്കപ്പെടുന്നു എന്ന് തീരുമാനിക്കുക

shim ഉള്ളപ്പോൾ കണ്ടെയ്നറിന് ഹോസ്റ്റിൽ എത്താം, ചോദ്യം മറുപടി ഏത് സ്രോതസ്സ് വിലാസം വഹിക്കുന്നു എന്നതാകുന്നു. യഥാർത്ഥ VPN സ്രോതസ്സ് സംരക്ഷിക്കുന്നതാണ് ശുദ്ധമായ മാതൃക: കണ്ടെയ്നർ ക്ലയന്റിന്റെ യഥാർത്ഥ വിലാസം കാണുന്നു, സേവനത്തിന്റെ ലോഗുകൾക്കും ആക്സസ് നിയമങ്ങൾക്കും അത് ഉപയോഗിക്കാം.

അത് പ്രവർത്തിക്കാൻ, കണ്ടെയ്നറിന്റെ നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷൻ ഈ വഴിക്ക് 10.95.0.0/24-ന്റെ ട്രാഫിക് 192.168.60.250-ലേക്ക് അതിന്റെ ഗേറ്റ്‌വേ ആയി അയയ്ക്കണം. ഇത് കണ്ടെയ്നറിന്റെ സ്വന്തം കോൺഫിഗറേഷനുള്ളിൽ പിന്തുണയ്ക്കുന്ന റൂട്ട് അല്ലെങ്കിൽ ഗേറ്റ്‌വേ ക്രമീകരണമാണ്, ഹോസ്റ്റ് വശത്തെ തന്ത്രമല്ല. ക്രമീകരണം പ്രാബല്യത്തിൽ വന്നു എന്ന് അനുമാനിക്കുന്നതിനുപകരം കണ്ടെയ്നറിനുള്ളിൽ നിന്ന് അത് സ്ഥിരീകരിക്കുക. ഇപ്പോഴും LAN റൂട്ടറിലേക്ക് ചൂണ്ടുന്ന ഡിഫോൾട്ട് ഗേറ്റ്‌വേ മറുപടികൾ അതേ ദ്വാരത്തിലേക്ക് അയച്ചുകൊണ്ടിരിക്കും.

അംഗീകരിച്ച രൂപകൽപ്പന പകരം VPN സ്രോതസ്സുകൾ മറയ്ക്കുന്നുവെങ്കിൽ, വിവർത്തനം ഇടുങ്ങിയതായി പരിമിതപ്പെടുത്തുക: യഥാർത്ഥ VPN പൂൾ, ഔട്ട്ഗോയിംഗ് ഇന്റർഫേസായി shim, കൂടാതെ നിർദ്ദിഷ്ട കണ്ടെയ്നറും സേവനവും.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

shim-നെ എഗ്രെസ് ഇന്റർഫേസായി പൊരുത്തപ്പെടുത്തുക, ടണൽ അല്ല. ടണലിനെ ഔട്ട്ഗോയിംഗ് ഇന്റർഫേസ് എന്ന് പേരിടുന്ന നിയമം കണ്ടെയ്നറിലേക്ക് പോകുന്ന പാക്കറ്റുമായി പൊരുത്തപ്പെടില്ല, ഇത്തരം ക്രമീകരണങ്ങളിൽ സാധാരണയായി ഈ തെറ്റാണ് ഉള്ളത്. നിയമം മുകളിലെ വാക്യത്തോളം ഇടുങ്ങിയതായി നിലനിർത്തുക, പൂൾ മാറുമ്പോൾ അത് പുനഃപരിശോധിക്കുക.

ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക, ഹോസ്റ്റിൽ നിന്നല്ല

ഹോസ്റ്റിൽ നിന്നുതന്നെ shim വിലാസത്തിലേക്ക് ബന്ധിച്ച ഒരു അഭ്യർത്ഥന shim-ന് കണ്ടെയ്നറിൽ എത്താമെന്ന് തെളിയിക്കുന്നു. എന്നാൽ സംരക്ഷിത 10.95.0.x സ്രോതസ്സിലേക്ക് കണ്ടെയ്നറിന് ട്രാഫിക് തിരികെ അയയ്ക്കാമെന്ന് അത് തെളിയിക്കുന്നില്ല, കാരണം ആ പരിശോധനയിലെ സ്രോതസ്സ് വിലാസം shim-ന്റേതാണ്.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

ആദ്യ കമാൻഡ് ഹോസ്റ്റിൽ നിന്ന് കണ്ടെയ്നർ വരെയുള്ള ഭാഗം പരിശോധിക്കുന്നു, രണ്ടാമത്തേത് യഥാർത്ഥ VPN ക്ലയന്റ് അഭ്യർത്ഥന നടത്തുമ്പോൾ shim-ലൂടെ യഥാർത്ഥത്തിൽ എന്ത് കടന്നുപോകുന്നു എന്ന് കാണിക്കുന്നു. വരവിലെ വഴിയിൽ സ്രോതസ്സ് വിലാസവും അതേ പ്രവാഹത്തോടെ മറുപടി പ്രത്യക്ഷപ്പെടുന്നുണ്ടോ എന്നും നോക്കുക.

ഹോസ്റ്റിൽ ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമായിരിക്കണം, ഫോർവേഡിംഗ് വഴിക്ക് സേവന പോർട്ടിൽ VPN പൂളിൽ നിന്ന് shim-ലേക്ക് അനുമതിയും സ്ഥാപിത മറുപടികൾക്ക് അനുമതിയും വേണം. ഹോസ്റ്റിലെ INPUT നിയമം ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക്കിന് അധികാരം നൽകുന്നില്ല, റൂട്ടിംഗ് ശരിയായി തോന്നിയതിന് ശേഷം പാക്കറ്റ് ഉപേക്ഷിക്കപ്പെടുന്നതിന് ഇത് സാധാരണ കാരണമാണ്.

യഥാർത്ഥ അപ്ലിക്കേഷൻ യഥാർത്ഥ ക്രെഡൻഷ്യലുകളോടെ പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് അതേ കണ്ടെയ്നറിലെ രണ്ടാമത്തെ, ബന്ധമില്ലാത്ത സേവനം ഇപ്പോഴും നിങ്ങളെ നിരസിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. അത് പ്രവർത്തിപ്പിക്കാനുള്ള ഏക മാർഗം എല്ലാ ഫോർവേഡിംഗ് നിയമങ്ങളും തുറക്കുക എന്നതായിരുന്നെങ്കിൽ, രൂപകൽപ്പന പൂർത്തിയായിട്ടില്ല. സേവനം ഏത് സ്രോതസ്സ് വിലാസം രേഖപ്പെടുത്തി എന്നതും ശ്രദ്ധിക്കുക, കാരണം ഇനി മുതൽ അതിന്റെ സ്വന്തം ആക്സസ് നിയമങ്ങൾ അതാണ് ഉപയോഗിക്കുക.