OpenVPN റൂട്ട് മെട്രിക്: തിരഞ്ഞെടുത്ത റൂട്ട് എന്തുകൊണ്ട് ഇപ്പോഴും തോൽക്കുന്നു

പ്രൊഫൈലിലെ ഒരു റൂട്ടിലേക്ക് മെട്രിക് ചേർത്തു, വീണ്ടും കണക്ട് ചെയ്തു, എന്നിട്ടും ട്രാഫിക് തെറ്റായ ഇന്റർഫേസിലൂടെയാണ് പുറത്തുപോകുന്നത്. പ്രശ്നം അപൂർവ്വമായി സംഖ്യയിലാണ്. മെട്രിക് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഇതിനകം താരതമ്യം ചെയ്യുന്ന സ്ഥാനാർത്ഥികളെ മാത്രം ക്രമീകരിക്കുന്നു, കൂടുതൽ നിർദ്ദിഷ്ടമായ പ്രിഫിക്സോ മുൻകൂട്ടിയുള്ള പോളിസി പട്ടികയോ ഏതെങ്കിലും മെട്രിക് വായിക്കുന്നതിന് മുമ്പ് തന്നെ തീരുമാനിക്കുന്നു.

ആദ്യം പ്രൊഫൈലിലൂടെ, തുടർന്ന് ഇൻസ്റ്റാൾ ചെയ്ത പട്ടികയിലൂടെ, ഒടുവിൽ തിരഞ്ഞെടുപ്പ് നിയമങ്ങളിലൂടെ പോകുക. ആ ക്രമം ക്ലയന്റ് റൂട്ട് നിർമ്മിക്കുന്ന രീതിയുമായി യോജിക്കുന്നു, താരതമ്യത്തിൽ ഒരിക്കലും എത്താത്ത ഒരു മൂല്യം ട്യൂൺ ചെയ്യുന്നതിൽ നിന്ന് നിങ്ങളെ തടയുന്നു.

ഫീൽഡ് ക്രമത്തിൽ റൂട്ട് വരി വായിക്കുക

Community OpenVPN 2.6 ക്ലയന്റ് IPv4 route വരിയിൽ നാല് ഫീൽഡുകൾ സ്വീകരിക്കുന്നു: നെറ്റ്വർക്ക്, നെറ്റ്മാസ്ക്, ഗേറ്റ്വേ, ഒപ്പം ഓപ്ഷണൽ മെട്രിക്. ഗേറ്റ്വേ സ്ഥാനത്താണ് പ്രത്യേക vpn_gateway കീവേഡ് വരുന്നത്. ഇത് ഈ കണക്ഷനുള്ള VPN വശത്തെ അടുത്ത ഹോപ്പ് എന്നാണ് അർത്ഥം, റൂട്ടിംഗ് ടേബിൾ നമ്പറല്ല, നിങ്ങളുടെ ഫിസിക്കൽ റൂട്ടറുമല്ല. ഇത് വിട്ടുപോയാൽ, വരിയുടെ ബാക്കി ഭാഗം അത് എന്ത് ചെയ്യുന്നു എന്നതിനെക്കുറിച്ചുള്ള തെറ്റായ ധാരണയോടെയാണ് വായിക്കപ്പെടുന്നത്. network-options റഫറൻസ് നാല് ഫീൽഡുകളും രേഖപ്പെടുത്തുന്നു.

സ്വകാര്യ ലക്ഷ്യസ്ഥാനത്തിന് വരി ഇങ്ങനെയാകാം:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

വ്യക്തമായ 30 ആ റൂട്ടിന് ബാധകമാണ്, 50 പ്രൊഫൈലിൽ സംഖ്യ ഒഴിവാക്കുന്ന മറ്റെല്ലാ റൂട്ടുകൾക്കും ഡിഫോൾട്ടായി തുടരുന്നു. വരി ഇടത്തുനിന്ന് വലത്തോട്ട് വായിച്ചാൽ ഏത് മൂല്യം എവിടെ ബാധകമാണെന്ന് പറയാൻ മതി.

route-metric ഒരു ഡിഫോൾട്ടാണ്, റാങ്കല്ല

സ്വന്തം സംഖ്യ ഇല്ലാത്ത റൂട്ടുകൾക്കുള്ള ഫാൾബാക്ക് route-metric സജ്ജീകരിക്കുന്നു. അത് ഒരു റൂട്ടിനെ മറ്റെന്തിനെക്കാളും മുകളിലേക്ക് തള്ളുന്നില്ല, വ്യക്തമായ മെട്രിക്കുകളോടെ ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകളെ പുനഃക്രമീകരിക്കുന്നുമില്ല.

പ്രൊഫൈൽ രണ്ട് രൂപങ്ങളും കലർത്തുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്. മുകളിലുള്ള ഒരൊറ്റ route-metric വരി അധികാരമുള്ളതായി തോന്നും, കുറ്റപ്പെടുത്താൻ എളുപ്പമാണ്, എന്നാൽ യഥാർത്ഥത്തിൽ ട്രാഫിക് വഹിക്കുന്ന റൂട്ട് മൂന്ന് വരികൾ താഴെ സ്വന്തം മെട്രിക് വഹിച്ചേക്കാം.

ഒരു റൂട്ട് ഒരു പാതയെ മുൻഗണന നൽകണമെങ്കിൽ, സംഖ്യ ആ റൂട്ടിൽ ഇടുക. സൃഷ്ടിച്ച പ്രൊഫൈലിലുടനീളം സ്ഥിരമായ ഡിഫോൾട്ട് വേണമെങ്കിൽ, route-metric ഉപയോഗിച്ച് വ്യക്തിഗത വരികൾ അനങ്ങാതെ വിടുക. കാരണമില്ലാതെ രണ്ടും കലർത്തുന്നതാണ് ആർക്കും വിശദീകരിക്കാൻ കഴിയാത്ത ഒരു റൂട്ടുമായി പ്രൊഫൈൽ അവസാനിക്കുന്ന വഴി.

ക്ലയന്റ് എന്ത് ഇൻസ്റ്റാൾ ചെയ്തു എന്ന് പരിശോധിക്കുക

വീണ്ടും കണക്ട് ചെയ്യൽ പൂർത്തിയായാൽ, പ്രൊഫൈലിനോടല്ല, കേർണലിനോട് ചോദിക്കുക.

ക്ലയന്റ് ചേർത്ത റൂട്ടുകൾ ip route show പട്ടികപ്പെടുത്തുന്നു, ip route get 172.20.5.10 കൂടുതൽ ഉപയോഗപ്രദമായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ ലക്ഷ്യസ്ഥാനം ഏത് റൂട്ട് ഏത് സോഴ്സ് വിലാസത്തോടെ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കും. ലക്ഷ്യസ്ഥാനം പട്ടികയിൽ ഇല്ലെങ്കിൽ, ക്ലയന്റ് അത് ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ല.

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

ചെറിയ മെട്രിക് എന്തുകൊണ്ട് ഇപ്പോഴും തോൽക്കുന്നു

ഒരേ ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള റൂട്ടുകളെയാണ് മെട്രിക്കുകൾ താരതമ്യം ചെയ്യുന്നത്. വിശാലമായ പ്രിഫിക്സിനെ അവ കൂടുതൽ നിർദ്ദിഷ്ടമാക്കുന്നില്ല. redirect-gateway def1 ഉപയോഗത്തിലിരിക്കുമ്പോൾ, ക്ലയന്റ് 0.0.0.0/1, 128.0.0.0/1 എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ആ രണ്ട് പ്രിഫിക്സുകൾ 0.0.0.0/0-നെക്കാൾ കൃത്യമായി മുഴുവൻ IPv4 ഇടവും ഉൾക്കൊള്ളുന്നു. ഡിഫോൾട്ട് റൂട്ടിലെ 1 എന്ന മെട്രിക് അവയെ മറികടക്കുന്നില്ല.

ഏത് ഓവർലാപ്പിംഗ് ജോടിക്കും ഇതേ യുക്തി ബാധകമാണ്. ഉള്ളിലെ ഒരു വിലാസത്തിന് /24 /16-നെ തോൽപ്പിക്കുന്നു, സംഖ്യകൾ എന്തായാലും, കാരണം ലുക്കപ്പ് ആദ്യം ഏറ്റവും നിർദ്ദിഷ്ടമായ പൊരുത്തം തിരഞ്ഞെടുക്കുന്നു, അതിനുശേഷം മാത്രം തുല്യരുടെ ഇടയിൽ മെട്രിക്കുകൾ താരതമ്യം ചെയ്യുന്നു.

ഇത് മെട്രിക് ബഗ് പോലെ തോന്നുന്ന, എന്നാൽ അല്ലാത്ത ഭാഗമാണ്. ഏതെങ്കിലും സംഖ്യ മാറ്റുന്നതിന് മുമ്പ് രണ്ട് സ്ഥാനാർത്ഥികളിലും പ്രിഫിക്സ് നീളം പരിശോധിക്കുക.

പോളിസി നിയമങ്ങൾ പട്ടികയ്ക്ക് മുമ്പ് പ്രവർത്തിക്കുന്നു

Linux-ൽ, ഏത് റൂട്ടിംഗ് പട്ടിക പരിശോധിക്കണം എന്ന് ip rule തീരുമാനിക്കുന്നു. നിയമങ്ങൾ മുൻഗണനാ ക്രമത്തിൽ വിലയിരുത്തപ്പെടുന്നു, അതിനാൽ പ്രധാന പട്ടിക വായിക്കുന്നതിന് മുമ്പ് തന്നെ മുൻകൂട്ടിയുള്ള പട്ടിക ഒരു റൂട്ട് തിരികെ നൽകാം. പ്രധാനത്തിനുള്ളിലെ ഒരു മെട്രിക് ആദ്യം പരിശോധിച്ച പട്ടികയിലെ പൊരുത്തത്തെ മറികടക്കാൻ കഴിയില്ല.

ip rule show ഉപയോഗിച്ച്, അതിനുശേഷം നിർദ്ദിഷ്ട പട്ടിക ചോദിക്കുക, ഉദാഹരണത്തിന് ip route show table 100, ആ നിയമം എന്ത് തിരികെ നൽകുമെന്ന് കാണാൻ. ഒരു VPN ക്ലയന്റോ കണ്ടെയ്നർ റൺടൈമോ ഒരു നിയമം ചേർത്തിട്ടുണ്ടെങ്കിൽ, ഉത്തരം നിങ്ങൾ വായിച്ചുകൊണ്ടിരുന്ന പട്ടികയിലല്ല, അവിടെയായിരിക്കാം. സോഴ്സ് വിലാസവും പ്രധാനമാണ്, കാരണം ഒരു നിയമം സോഴ്സുമായി പൊരുത്തപ്പെട്ട് ഒരേ ലക്ഷ്യസ്ഥാനം ടണൽ ട്രാഫിക്കിനും LAN ട്രാഫിക്കിനും വ്യത്യസ്തമായി പരിഹരിക്കാം.

ലക്ഷ്യസ്ഥാനം പരിശോധിക്കുക, റാങ്കിംഗ് അല്ല

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

IPv6-ഉം DNS-ഉം ഈ പരിശോധനയിൽ നിന്ന് ഒഴിവാക്കുക. അവ വ്യത്യസ്ത ഡയറക്ടീവുകളാൽ കോൺഫിഗർ ചെയ്യപ്പെടുന്നു, വ്യത്യസ്ത സംവിധാനങ്ങളാൽ പരിഹരിക്കപ്പെടുന്നു, പ്രവർത്തിക്കുന്ന IPv4 റൂട്ട് അവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഒരു ലെയർ വീതം മാറ്റി ചോദ്യം വീണ്ടും പ്രവർത്തിപ്പിക്കുക.