fwmark ഉപയോഗിച്ച് ഒരു Linux ഹോസ്റ്റിൽ രണ്ട് OpenVPN ക്ലയന്റുകൾ കൂട്ടിച്ചേർക്കുക

ഒരു Linux ഹോസ്റ്റിൽ രണ്ടാമത്തെ OpenVPN ക്ലയന്റ് കൂട്ടിച്ചേർക്കുമ്പോൾ രണ്ട് സ്ഥലങ്ങളിൽ ഒന്നിൽ പരാജയപ്പെടുന്നു. ഒന്നുകിൽ പുറം ടണൽ ആ ഗതാഗതം പിടിച്ചെടുത്തതിനാൽ ഉള്ളിലെ ക്ലയന്റിന് സ്വന്തം സർവറിൽ എത്താൻ കഴിയില്ല, അല്ലെങ്കിൽ രണ്ടാമത്തെ ക്ലയന്റ് റൂട്ട് പട്ടിക വീണ്ടും എഴുതുന്നതിനാൽ ആദ്യ ടണൽ പ്രവർത്തനം നിർത്തുന്നു. രണ്ട് പ്രശ്നങ്ങളും റൂട്ടിംഗിലാണ്, എൻക്രിപ്ഷനിലല്ല, കൂടാതെ പുതിയ ടണൽ ഏതെങ്കിലും ആപ്ലിക്കേഷൻ ട്രാഫിക് കൊണ്ടുപോകുന്നതിന് മുൻപ് രണ്ടും പരിഹരിക്കപ്പെടുന്നു. ഇവിടത്തെ വിലാസങ്ങൾ ഉദാഹരണത്തിനാണ്: tun0 പുറം ടണൽ, 203.0.113.9 ഉള്ളിലെ സർവർ, TCP 9999 ഉള്ളിലെ വഴി ഉപയോഗിക്കേണ്ട ഫ്ലോ.

രണ്ട് പരാജയ മാതൃകകൾ, ഒരു റൂട്ട് പട്ടിക

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

രണ്ടാമത്തെ പരാജയം സർവർ push-ൽ നിന്നാണ്. സാധാരണ push redirect-gateway def1 ആണ്, അത് ഡിഫോൾട്ട് റൂട്ട് മാറ്റുന്നതിനുപകരം 0.0.0.0/1, 128.0.0.0/1 എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. അതിനാൽ സ്വന്തം /1 ജോഡി ഇൻസ്റ്റാൾ ചെയ്യുന്ന രണ്ട് ക്ലയന്റുകൾ കൂട്ടിയിടിക്കുന്നു, ഏറ്റവും പുതിയ ജോഡി മിക്കവാറും എല്ലാ ലക്ഷ്യസ്ഥാനത്തിനും വിജയിക്കുന്നു. രണ്ടാമത്തേത് കണക്ട് ചെയ്തതിന് ശേഷം ടണൽ മരിക്കുമ്പോൾ പട്ടികയിൽ ആ രണ്ട് പ്രിഫിക്സുകൾ നോക്കുക, കാരണം ഡിഫോൾട്ട് റൂട്ട് തന്നെ ഒരിക്കലും മാറിയിട്ടുണ്ടാകണമെന്നില്ല.

ഫ്ലോ അടയാളപ്പെടുത്തി അതിന് ഒരു പട്ടിക നൽകുക

തിരഞ്ഞെടുത്ത ട്രാഫിക് mangle പട്ടികയിൽ അടയാളപ്പെടുത്തി നയ നിയമത്തിൽ ആ അടയാളം ചേർത്ത് വഴിതിരിച്ചുവിടുക. നിയമം ഡിഫോൾട്ട് റൂട്ട് ഉള്ളിലെ ഉപകരണമായുള്ള സമർപ്പിത പട്ടികയിലേക്ക് ചൂണ്ടുന്നു, അതിനാൽ അടയാളപ്പെടുത്തിയ പാക്കറ്റുകൾ മാത്രം ഉള്ളിലെ വഴി സ്വീകരിക്കുന്നു.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

ഈ നിയമ കൂട്ടത്തിലെ മിക്ക പരാജയങ്ങളും രണ്ട് തെറ്റുകളിൽ നിന്നാണ്. firewall സജ്ജമാക്കുന്ന അടയാള മൂല്യവും നിയമം ചേർക്കുന്ന മൂല്യവും ഒന്നുതന്നെയായിരിക്കണം, കാരണം വ്യത്യാസം പിശകും ഫലവും നൽകുന്നില്ല. PREROUTING പുറത്തുനിന്ന് വരുന്ന പാക്കറ്റുകൾ മാത്രം കാണുന്നു, അതിനാൽ ഈ ഹോസ്റ്റിൽ തുടങ്ങുന്ന കണക്ഷന് അടയാളപ്പെടുത്തുന്നതിന് മുൻപ് അതേ ചേർച്ചയുള്ള OUTPUT നിയമം വേണം.

രണ്ടാമത്തെ ക്ലയന്റിൽ നിന്ന് റൂട്ട് ഉടമസ്ഥത എടുത്തുകളയുക

രണ്ട് ഓപ്ഷനുകൾ രണ്ടാമത്തെ ക്ലയന്റ് പട്ടിക തിരുത്തുന്നത് തടയുന്നു, അവ വ്യത്യസ്ത ഘട്ടങ്ങളിൽ പ്രവർത്തിക്കുന്നു. route-nopull push ചെയ്ത റൂട്ട് ഓപ്ഷനുകൾ അവഗണിക്കുന്നു, അതിനാൽ ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല. route-noexec push ചെയ്ത ഓപ്ഷനുകൾ ക്ലയന്റിന്റെ പരിസ്ഥിതിയിൽ സ്വീകരിക്കുന്നു, പക്ഷേ പട്ടിക മാറ്റം ഒരു hook-ന് വിടുന്നു, സർവർ എന്താണ് വാഗ്ദാനം ചെയ്തതെന്ന് കാണേണ്ടിവരുമ്പോൾ അതാണ് വേണ്ടത്.

Hook push ചെയ്ത മൂല്യങ്ങളുമായി സ്വന്തം പരിസ്ഥിതിയിൽ പ്രവർത്തിക്കുന്നു, നിങ്ങൾ അംഗീകരിച്ച എൻട്രികൾ മാത്രം ചേർക്കണം. അതിനെ idempotent ആക്കുക: പുനർനിർമ്മിക്കുന്നതിന് മുൻപ് അതിന്റെ കൈവശമുള്ള പട്ടിക ശൂന്യമാക്കുക, മുൻപത്തെ പ്രവർത്തനം വൃത്തിയുള്ള അവസ്ഥ വിട്ടുവെന്ന് കരുതരുത്. വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ hook വീണ്ടും വിളിക്കപ്പെടുന്നു, വൃത്തിയാക്കാതെ ചേർക്കുന്ന hook ഇരട്ടി റൂട്ടുകൾ കൂട്ടുന്നു.

ഒരു ഉടമയെ തിരഞ്ഞെടുത്ത് അത് എഴുതിവയ്ക്കുക. രണ്ട് ഓപ്ഷനുകളും സജ്ജമാക്കുന്ന പ്രൊഫൈലോ കൈയെഴുത്ത് സ്ക്രിപ്റ്റുമായി മത്സരിക്കുന്ന hook-ഓ പിന്നീട് ആർക്കും വിശദീകരിക്കാൻ കഴിയാത്ത പട്ടിക സൃഷ്ടിക്കുന്നു.

രണ്ട് സർവർ വിലാസങ്ങളും പിന്ന് ചെയ്യുക

ഉള്ളിലെ ക്ലയന്റ് കണക്ട് ചെയ്യുന്നതിന് മുൻപ് ഉള്ളിലെ സർവറിന് പുറം ഉപകരണത്തിലൂടെ ഒരു ഹോസ്റ്റ് റൂട്ട് വേണം. ആ എൻട്രിയാണ് ഉള്ളിലെ ഗതാഗതം ഡിഫോൾട്ട് പിന്തുടരാൻ അനുവദിക്കാതെ പുറം ടണലിനുള്ളിൽ നിർത്തുന്നത്.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

പ്രധാന പട്ടികയിൽ പുറം സർവറിനും ചേരുന്ന ഹോസ്റ്റ് റൂട്ട് ചേർക്കുക, അല്ലെങ്കിൽ വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ പുറം ക്ലയന്റിന്റെ സ്വന്തം ഗതാഗതം അതിന്റെ സ്വന്തം ടണലിലേക്ക് റൂട്ട് ചെയ്തേക്കാം. ക്രമം നിർബന്ധമാണ്: ബന്ധപ്പെട്ട ഇന്റർഫേസ് നിലവിൽ വന്നതിന് ശേഷം ഈ എൻട്രികൾ ചേർക്കുക, അതായത് കണക്ഷന് ശേഷം പ്രവർത്തിക്കുന്ന hook അല്ലെങ്കിൽ സ്ക്രിപ്റ്റ്. ഓഫ് ആയ ഉപകരണത്തിലേക്ക് ചൂണ്ടുന്ന റൂട്ട് നീക്കം ചെയ്യപ്പെടുകയോ അവഗണിക്കപ്പെടുകയോ ചെയ്യുന്നു, അതിനാൽ ബൂട്ട് സമയത്ത് എഴുതിയ എൻട്രി നിങ്ങൾ കരുതിയ ക്രമം അതിജീവിക്കുന്നില്ല.

മുഴുവൻ പട്ടികയും വായിക്കുന്നതിനുപകരം ലുക്കപ്പ് പരിശോധിക്കുക. റൂട്ട് ലുക്കപ്പിന്റെ ഔട്ട്പുട്ട് kernel ഉപയോഗിക്കുന്ന ഉപകരണവും ഉറവിട വിലാസവും പേരിടുന്നു, ക്ലയന്റ് സോക്കറ്റ് തുറക്കുമ്പോൾ കൃത്യമായി അതാണ് ലഭിക്കുന്നത്.

ചെയിൻ പരീക്ഷിച്ച് പരാജയം കാണാവുന്നതാക്കുക

ഉള്ളിലെ ക്ലയന്റ് കണക്ട് ചെയ്യുമ്പോൾ പുറം ഇന്റർഫേസിൽ ക്യാപ്ചർ ചെയ്യുക. ഉള്ളിലെ ഹാൻഡ്ഷേക്ക് പുറം ടണലിനുള്ളിൽ എൻക്രിപ്റ്റ് ചെയ്ത പേലോഡായി കാണണം; അത് 203.0.113.9-ലേക്ക് സാധാരണ UDP ആയി കാണുന്നുവെങ്കിൽ ഹോസ്റ്റ് റൂട്ട് ഇല്ല, ചെയിൻ ഒരിക്കലും നിർമ്മിക്കപ്പെട്ടിട്ടില്ല.

ഭൗതിക അപ്പ്‌ലിങ്കിലേക്ക് നിശബ്ദമായി മടങ്ങുന്ന ചെയിനാണ് ഏറ്റവും മോശം ഫലം, കാരണം ഇന്റർഫേസ് അവസ്ഥ ഒന്നും പ്രഖ്യാപിക്കുന്നില്ല, ഉള്ളിലെ ട്രാഫിക് തെറ്റായ ഉറവിട വിലാസത്തിൽ നിന്ന് പുറത്തുപോകുന്നു. പുറം ടണൽ വീഴുമ്പോൾ രണ്ടാമത്തെ ക്ലയന്റിന് നേരിട്ട് വീണ്ടും കണക്ട് ചെയ്യാൻ കഴിയുമെങ്കിൽ ആ വഴി അപ്രാപ്തമാക്കുക അല്ലെങ്കിൽ പരാജയം കാണാനായി അത് പുറം ഇന്റർഫേസുമായി ബന്ധിപ്പിക്കുക.

രണ്ട് ഫ്ലോകളും ഒരു നിയമ ഡംപും കൊണ്ട് അവസാനിപ്പിക്കുക: അടയാളപ്പെടുത്തിയതും അടയാളപ്പെടുത്താത്തതുമായ കണക്ഷനുകൾ വ്യത്യസ്ത വഴികൾ സ്വീകരിക്കണം, ip rule show നിങ്ങൾ ഉദ്ദേശിച്ച മുൻഗണന പട്ടികപ്പെടുത്തണം. രണ്ട് ഫ്ലോകളും ഒരേ വഴി സ്വീകരിക്കുന്നുവെങ്കിൽ, അടയാളം നിങ്ങൾ കരുതുന്നിടത്ത് പ്രയോഗിക്കപ്പെടുന്നില്ല.