വേറിട്ട ഇഗ്രെസ്: usb0-യിൽ VPN പൂൾ, eth0-യിൽ ഗേറ്റ്‌വേ ട്രാഫിക്

ക്ലയന്റുകൾ കണക്ട് ചെയ്ത് ആധികാരികീകരിക്കുന്നു, പിന്നീട് അവരുടെ ട്രാഫിക് തെറ്റായ അപ്‌ലിങ്ക് വഴി പുറത്തുപോകുന്നു, കാരണം യന്ത്രത്തിലെ ഏക ഡിഫോൾട്ട് റൂട്ട് ഗേറ്റ്‌വേയുടേതാണ്. ആ ഡിഫോൾട്ട് മാറ്റിയാൽ യന്ത്രത്തിന്റെ സ്വന്തം അപ്ഡേറ്റുകളും മാനേജ്‌മെന്റ് ആക്സസും തകരും, അതിനാൽ തിരഞ്ഞെടുപ്പ് «എല്ലാ ട്രാഫിക്കി»നേക്കാൾ ഇടുങ്ങിയതായിരിക്കണം. പ്രവർത്തനക്ഷമമായ രൂപം ക്ലയന്റ് പൂളിന്റെ ആന്തരിക സ്രോതസ്സ് വിലാസത്തെ അടിസ്ഥാനമാക്കിയുള്ളതും ബദൽ WAN ഉള്ള രണ്ടാം റൂട്ടിംഗ് പട്ടികയിലേക്ക് ചൂണ്ടുന്നതുമായ ഒരു നയ നിയമമാണ്. അവിടെ നിന്ന് ചെക്ക്‌ലിസ്റ്റ് നിയമത്തെക്കുറിച്ചല്ല, പൂർണ്ണതയെയും പരാജയ സ്വഭാവത്തെയും കുറിച്ചാണ്.

സ്രോതസ്സ് വിലാസം റൂട്ടിംഗ് തീരുമാനം വരെ നിലനിൽക്കുന്നുവെന്ന് ഉറപ്പാക്കുക

സ്രോതസ്സ് ശ്രേണിയുമായി പൊരുത്തപ്പെടുന്ന നയ നിയമം ലുക്കപ്പ് സമയത്ത് പാക്കറ്റ് ആ സ്രോതസ്സ് ഇപ്പോഴും വഹിക്കുമ്പോൾ മാത്രമാണ് സജീവമാകുന്നത്. ഫോർവേഡ് ചെയ്ത ക്ലയന്റ് ട്രാഫിക് അങ്ങനെ ചെയ്യുന്നു, റൂട്ടിംഗിന് മുമ്പ് മുകളിൽ ഒന്നും അത് വീണ്ടും എഴുതിയിട്ടില്ലെങ്കിൽ. ഗേറ്റ്‌വേ തന്നെ സൃഷ്ടിക്കുന്ന ട്രാഫിക് അങ്ങനെ ചെയ്യുന്നില്ല, അതുകൊണ്ടുതന്നെ ഗേറ്റ്‌വേയുടെ സ്വന്തം ഡിഫോൾട്ട് അതിന്റെ സ്ഥാനത്ത് തുടരാം.

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

യഥാർത്ഥ മൂല്യങ്ങൾ എഴുതിയെടുത്തുകൊണ്ട് തുടങ്ങുക: പൂൾ പ്രിഫിക്സ്, അത് വഹിക്കുന്ന ടണൽ ഇന്റർഫേസ്, രണ്ടാം WAN-ന്റെ വിലാസവും അടുത്ത ഹോപ്പും, നിങ്ങൾ ഉപയോഗിക്കാൻ ഉദ്ദേശിക്കുന്ന പട്ടിക നമ്പറും. പുതിയ നിയമങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ് മുൻ ശ്രമത്തിന്റെ പഴയ നിയമങ്ങൾ മായ്ക്കുക, കാരണം വ്യത്യസ്ത മുൻഗണനകളിലുള്ള ഇരട്ട നിയമങ്ങൾ ക്രമരഹിതമെന്ന് തോന്നുന്ന പരാജയങ്ങൾ സൃഷ്ടിക്കുന്നു.

പൂർണ്ണമായ തിരഞ്ഞെടുത്ത പട്ടിക നിർമ്മിക്കുക

പട്ടിക ഒരു സുഹൃത്തുള്ള ഡിഫോൾട്ട് റൂട്ടല്ല. ഓരോ ലുക്കപ്പും അതിനുള്ളിൽ തീരുന്നതിന് മതിയായ റൂട്ടുകൾ വേണം, അടുത്ത ഹോപ്പ് എത്തിച്ചേരാൻ WAN സബ്‌നെറ്റിന്റെ കണക്ടഡ് റൂട്ടും ഉൾപ്പെടെ. tun1-ൽ 10.77.0.0/24 പൂൾ, അടുത്ത ഹോപ്പ് 203.0.113.1 ഉള്ള WAN വിലാസം 203.0.113.20/24, പട്ടിക 600 എന്നിവയ്ക്ക്:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

നിയമം നിലവിലുള്ള ഏതൊരു എല്ലാം പിടിക്കുന്ന നിയമത്തിനും താഴെയുള്ള മുൻഗണനയിൽ ഇരിക്കുന്നു, അതിനാൽ പൊരുത്തപ്പെടുന്ന ക്ലയന്റുകൾ ആദ്യം പട്ടിക 600-ൽ എത്തുന്നു, ബാക്കിയെല്ലാം പ്രധാന പട്ടികയിലേക്ക് വീഴുന്നു. ip-rule റഫറൻസ് ക്രമീകരിച്ച ലുക്കപ്പ് മാതൃകയും സെലക്ടർ സിന്താക്സും പൂർണ്ണമായി വിവരിക്കുന്നു.

തുടർന്ന് പട്ടികയിൽ ഇല്ലാത്തതിനെക്കുറിച്ച് ചിന്തിക്കുക. പ്രധാനത്തിൽ മാത്രം റൂട്ടുള്ള ലക്ഷ്യസ്ഥാനം, ഉദാഹരണത്തിന് eth0 വഴി എത്താവുന്ന മാനേജ്‌മെന്റ് സബ്‌നെറ്റ്, പട്ടിക 600-ൽ കണ്ടെത്തില്ല, അവിടെ ഡിഫോൾട്ട് ഉണ്ടായാൽ പ്രധാനത്തിലേക്ക് തിരികെ പോകുകയുമില്ല. ആ പാതകൾ പ്രധാനമെങ്കിൽ അവ വ്യക്തമായി തിരഞ്ഞെടുത്ത പട്ടികയിൽ ചേർക്കുക, ഇതാണ് VPN ഇഗ്രെസ് പട്ടികയ്ക്ക് സാധാരണയായി ശരിയായ ഉത്തരം.

ശ്രോതാവിന്റെ സ്വന്തം ട്രാഫിക് നയത്തിന് പുറത്ത് നിർത്തുക

OpenVPN ശ്രോതാവിന് സ്വന്തം പുറം കണക്ഷനുണ്ട്, ക്ലയന്റ് അതിലെത്തിയ അപ്‌ലിങ്ക് വഴിയാണ് അത് വഹിക്കുന്നത്. ആ ട്രാഫിക് വന്ന തിരിച്ചുപോക്ക് പാത നിലനിർത്തണം, സെർവറിന്റെ പൊതു വിലാസമോ മുഴുവൻ ടണൽ ഇന്റർഫേസോ ഉൾക്കൊള്ളുന്ന വിശാല നിയമം അതിനെ ബദൽ പട്ടികയിലേക്ക് വലിച്ചിടാം. നിയമം ആന്തരിക പൂളിൽ മാത്രം പരിമിതപ്പെടുത്തുക, മറ്റൊന്നിലും അല്ല.

റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗും അതേ കാരണത്താൽ ശ്രദ്ധിക്കേണ്ടതാണ്. ക്ലയന്റുകൾക്കുള്ള മറുപടികൾ usb0 വഴി പോകുമ്പോൾ അഭ്യർത്ഥന മറ്റൊരു ലിങ്ക് വഴി വന്നാൽ, കർശനമായ rp_filter ക്രമീകരണം റൂട്ടിംഗ് നയം സാധുവായി കണക്കാക്കുന്ന പാക്കറ്റുകൾ ഉപേക്ഷിച്ചേക്കാം. നിയമം പരാജയപ്പെട്ടു എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് രണ്ട് ഇന്റർഫേസുകളിലെയും ഫലപ്രദമായ sysctl മൂല്യങ്ങൾ പരിശോധിക്കുക.

യന്ത്രത്തിലെ മറ്റെല്ലാത്തിനോടും ബന്ധപ്പെട്ട് ക്രമവും പ്രധാനമാണ്. Docker ബ്രിഡ്ജുകൾ, രണ്ടാം VPN, ദാതാവിന്റെ ഇമേജിൽ നിന്നുള്ള നിലവിലുള്ള നിയമങ്ങൾ എന്നിവയെല്ലാം മുൻഗണനകൾ ചേർക്കുന്നു, അതിനാൽ മുൻഗണന 100 ഒറ്റയ്ക്കാണെന്ന് കരുതാതെ മുഴുവൻ നിയമ പട്ടികയും വായിക്കുക.

ഫോർവേഡിംഗും വിവർത്തനവും റൂട്ടുമായി ഒത്തുപോകാൻ വയ്ക്കുക

റൂട്ടിംഗ് ഒരു അപ്‌ലിങ്ക് തിരഞ്ഞെടുക്കുന്നു; അത് ഫോർവേഡ് ചെയ്യാൻ അനുമതി നൽകുന്നില്ല. കെർണലിൽ IPv4 ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമായിരിക്കണം, ഫയർവാൾ ക്ലയന്റിൽ നിന്ന് WAN-ലേക്കുള്ള ദിശയും തിരിച്ചുള്ള ട്രാഫിക്കും സ്വീകരിക്കണം. ഒഴുക്ക് ഉപേക്ഷിക്കുന്ന FORWARD ചെയിനോടുകൂടിയ ശരിയായ പട്ടിക റൂട്ട് ഇല്ലാത്തതിന് സമാനമായ ലക്ഷണം നൽകുന്നു, അതിനാൽ രണ്ടും ഒരേ ഘട്ടത്തിൽ പരിശോധിക്കുന്നു.

രണ്ടാം WAN സ്വകാര്യ പൂൾ നിങ്ങളിലേക്ക് തിരികെ റൂട്ട് ചെയ്യുന്നില്ലെങ്കിൽ ആ ഇഗ്രെസിൽ സ്രോതസ്സ് വിവർത്തനം ചെയ്യുക. ചലനാത്മക വിലാസമുള്ള ഇന്റർഫേസിന് പൂളിലും ഇന്റർഫേസിലും പരിമിതപ്പെടുത്തിയ ഇടുങ്ങിയ masquerade നിയമമാണ് സാധാരണ തിരഞ്ഞെടുപ്പ്:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

ഇവിടെ ലക്ഷ്യത്തേക്കാൾ പ്രധാനം പരിധിയാണ്. ഏതെങ്കിലും പുറപ്പെടുന്ന ഇന്റർഫേസുമായി പൊരുത്തപ്പെടുന്ന masquerade നിയമം eth0 വഴി ശരിയായി പോകുന്ന ട്രാഫിക്കും വീണ്ടും എഴുതും, അത് റൂട്ടിംഗ് പിശകുകൾ തിരുത്തുന്നതിന് പകരം മറയ്ക്കുന്നു. വിവർത്തനം റൂട്ടിംഗ് തീരുമാനത്തിന് ശേഷം പ്രവർത്തിക്കുന്നു, അതിനാൽ തെറ്റായ അപ്‌ലിങ്കിലേക്ക് അയച്ച പാക്കറ്റ് ഒരിക്കലും നന്നാക്കാൻ കഴിയില്ല.

പാതകൾ വ്യത്യാസപ്പെടുമ്പോൾ ടണൽ ഓവർഹെഡും ശ്രദ്ധ ആവശ്യപ്പെടുന്നു. ക്ലയന്റുകൾ വലിയ TCP MSS-ൽ യോജിച്ചാൽ, ബദൽ WAN-ന് താഴ്ന്ന MTU ആണെങ്കിൽ അല്ലെങ്കിൽ അതിനുള്ളിൽ ടണൽ ഉണ്ടെങ്കിൽ, വലിയ സെഗ്‌മെന്റുകൾ നിലയ്ക്കും ചെറുത് പ്രവർത്തിക്കും. ഫോർവേഡിംഗ് പാതയിൽ MSS ക്ലാമ്പ് ചെയ്യുന്നത് അതിനെ ഇടയ്ക്കിടെ തടയുന്നതിന് പകരം പ്രവചനീയമായ സ്വഭാവമാക്കുന്നു.

usb0 അപ്രത്യക്ഷമാകുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക

ശൂന്യമായ പട്ടിക പരാജയത്തിൽ അടയുന്ന അവസ്ഥയല്ല. പൊരുത്തപ്പെടുന്ന റൂട്ട് അപ്രത്യക്ഷമായാൽ, ലുക്കപ്പ് അടുത്ത നിയമത്തിലേക്ക് തുടരുന്നു, പ്രധാന പട്ടികയിൽ എത്തി eth0 ഡിഫോൾട്ട് എടുക്കുന്നു. രണ്ടാം WAN വഴി പോകേണ്ടിയിരുന്ന ട്രാഫിക് നിശബ്ദമായി ആദ്യത്തേതിലൂടെ പോകുന്നു, നയ-റൂട്ടഡ് വിന്യാസത്തിൽ ഇതാണ് സാധാരണയായി നിങ്ങൾ ഏറ്റവും കുറവ് ആഗ്രഹിക്കുന്ന ഫലം.

ആ പിന്മാറ്റം സ്വീകാര്യമല്ലാത്തിടത്ത്, പട്ടിക 600-ൽ വ്യക്തമായ ടെർമിനൽ റൂട്ട് ചേർക്കുക, ഉദാഹരണത്തിന് blackhole ഡിഫോൾട്ട്, അല്ലെങ്കിൽ ഇന്റർഫേസ് ഓഫ് ആയിരിക്കുമ്പോൾ ഫയർവാളിൽ പൂൾ ഉപേക്ഷിക്കുക. രണ്ടിൽ ഏതും നിങ്ങൾക്ക് എഴുതിവയ്ക്കാവുന്ന തീരുമാനമാണ്; നിശബ്ദതയല്ല.

സ്ഥിരതയാണ് അവസാന ഇനം. രണ്ട് ലിങ്കുകളുടെയും ഉടമ ആരായാലും, അത് നെറ്റ്‌വർക്ക് മാനേജരോ ഡിസ്പാച്ചർ സ്ക്രിപ്റ്റോ കണക്ഷന്റെ ജീവിതചക്രമോ ആയാലും, ഓരോ പുനഃസംയോജനത്തിലും പകർപ്പുകൾ ചേർക്കാതെ റൂട്ടുകളും നിയമവും വീണ്ടും സൃഷ്ടിക്കണം. യഥാർത്ഥ ക്ലയന്റിൽ നിന്നുള്ള അഭ്യർത്ഥനയും ഗേറ്റ്‌വേയിൽ നിന്നുള്ള പ്രത്യേക അഭ്യർത്ഥനയും ഉപയോഗിച്ച് പരിശോധിക്കുക, രണ്ടിലും നിരീക്ഷിച്ച ഇഗ്രെസ് സ്ഥിരീകരിക്കുക, തുടർന്ന് രണ്ടാം WAN വലിച്ചൂരി നിങ്ങൾ രൂപകൽപ്പന ചെയ്ത രണ്ട് ഫലങ്ങളിൽ ഏതാണ് യഥാർത്ഥത്തിൽ സംഭവിക്കുന്നതെന്ന് നോക്കുക. IPv6-ന് സ്വന്തം പട്ടികയും നിയമവും വിവർത്തനവും വേണം; മുകളിലുള്ള IPv4 നിയമം അതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.