WireGuard-നുള്ളിൽ IPIP: ആരും ബജറ്റിൽ ഉൾപ്പെടുത്താത്ത അധിക 20 ബൈറ്റുകൾ

ചെറിയ ping-കൾ ദിവസം മുഴുവൻ ടണലിലൂടെ കടക്കുന്നു, SSH ബാനർ എത്തുന്നു, പിന്നീട് ഫയൽ കൈമാറ്റം ആരംഭിക്കുന്ന നിമിഷത്തിൽ സെഷൻ മരവിക്കുന്നു. ഈ മാതൃക തെറ്റായ പാളിയിൽ കണക്കാക്കിയ ബൈറ്റ് ബജറ്റിലേക്ക് വിരൽ ചൂണ്ടുന്നു, അവിടെ പുറം ടണൽ അതിന്റെ സ്വന്തം ഓവർഹെഡിനായി അളക്കപ്പെട്ടു, ഉള്ളിലേത് ആരും കുറച്ചില്ല. WireGuard-ന് ഉള്ളിൽ ഒതുക്കിയ IPIP പാക്കറ്റ് മറ്റൊരു IP പാക്കറ്റ് മാത്രമാണ്, അതുകൊണ്ടാണ് നിങ്ങൾ ഒരിക്കലും മാറ്റിവെക്കാത്ത ബൈറ്റുകൾ അത് ഉപയോഗിക്കുന്നത്. തിരുത്ത് ഗണിതമാണ്, അത് മൂന്ന് കമാൻഡിലും ഒരു പട്ടികയിലും ഒതുങ്ങുന്നു.

അത് വെളിപ്പെടുത്തുന്ന ലക്ഷണം

ഫ്രാഗ്മെന്റേഷൻ പ്രശ്നം വലിപ്പത്തിലൂടെയാണ് സ്വയം അറിയിക്കുന്നത്, വിലാസങ്ങളിലൂടെ ഒരിക്കലുമല്ല. നിങ്ങളുടെ പിയർ ഒരു മണിക്കൂർ 56 ബൈറ്റ് ping-ന് ഉത്തരം നൽകി, പിന്നീട് 1400 ബൈറ്റിൽ നിശബ്ദമാകുന്നു, ടണൽ ഉയർന്നു നിൽക്കുകയും ഒരു റൂട്ടും മാറാതിരിക്കുകയും ചെയ്യുന്നു. ഹാൻഡ്ഷേക്ക് ഒതുങ്ങുന്നു, ആദ്യ പൂർണ TCP വിൻഡോ ഒതുങ്ങുന്നില്ല, ആരോഗ്യകരമായി തോന്നിയതിന് ശേഷം സെക്കൻഡുകൾക്കുള്ളിൽ കൈമാറ്റം നിലയ്ക്കുന്നു.

എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് പരമാവധി പരിധി അളക്കുക, അളക്കാത്ത പരിധി നിങ്ങൾ രണ്ടുതവണ പിന്തുടരേണ്ടി വരുന്നതാണ്. സംശയാസ്പദമായ വലിപ്പത്തിന് താഴെ do-not-fragment ബിറ്റ് സെറ്റ് ചെയ്ത് ഒരു പ്രോബ് അയക്കുക, ping -M do -s 1000 10.9.0.2, പിന്നീട് വളരെ വലുതാണെന്ന് ഇതിനകം അറിയാവുന്ന വലിപ്പത്തിൽ ആവർത്തിക്കുക. ലക്ഷ്യസ്ഥാനം മാറാതെ തിരിച്ചുവരവ് പേലോഡിന്റെ വലിപ്പത്തെ പിന്തുടരുമ്പോൾ റൂട്ടിംഗ് അതിന്റെ ജോലി ചെയ്യുന്നു, ബജറ്റിൽ നിന്ന് ഒരു ഹെഡർ കുറവാണ്.

ഓരോ ഹെഡറും ഒരിക്കൽ, ശരിയായ പാളിയിൽ എണ്ണുക

ടണൽ ഇന്റർഫേസിൽ നിന്നല്ല, പാതയിലെ ഏറ്റവും ചെറിയ MTU-വിൽ നിന്ന് ആരംഭിക്കുക, കാരണം മതിൽ രണ്ടറ്റത്തിനും മുകളിലാണ്. WireGuard IPv4 പുറം ഗതാഗതത്തിന് 60 ബൈറ്റ് ചെലവാക്കുന്നു: 20 IP-ക്ക്, 8 UDP-ക്ക്, 32 അതിന്റെ സ്വന്തം ഹെഡറിന്, ആ ഗതാഗതം IPv6 ആണെങ്കിൽ 80 ബൈറ്റ്. 1420 ബൈറ്റ് wg0 1500 ബൈറ്റ് പാത യഥാർത്ഥത്തിൽ എത്തിക്കാൻ കഴിയുന്ന 1440-ന് താഴെ 20 ബൈറ്റ് ഇടം സൂക്ഷിക്കുന്നു, അതുകൊണ്ടാണ് വിക്കിയിൽ നിന്ന് പകർത്തിയ സംഖ്യ ഇവിടെയും യോജിക്കുന്നത്. മുഴുവൻ സ്റ്റാക്കും ഡയഗ്രാമിൽ വരയ്ക്കുക, അല്ലെങ്കിൽ അടുത്തതായി MTU മാറ്റുന്ന ആൾ പുതിയ ഒരു വൃത്തസംഖ്യ തിരഞ്ഞെടുത്ത് നിങ്ങളുടെ ബഗ്ഗ് പാരമ്പര്യമായി സ്വീകരിക്കും.

അഞ്ചാം വരിയാണ് ബജറ്റുകൾ കാടുകയറുന്നത്, കാരണം ഉള്ളിൽ ഒതുക്കിയ ഇന്റർഫേസ് വഹിക്കുന്ന 1400 ബൈറ്റിൽ യഥാർത്ഥ പാക്കറ്റിന്റെ സ്വന്തം 40 ബൈറ്റ് ഹെഡറുകൾ ഇതിനകം ഉൾപ്പെടുന്നു. ആ ബൈറ്റുകളിൽ 1360 മാത്രമാണ് ഫയൽ വായിക്കുന്ന പ്രോസസ്സിലെത്തുന്നത്. 1400-നെ ആപ്ലിക്കേഷൻ പേലോഡായി കാണുക, ആ നിരയില്ലാത്ത ഏത് ഡയഗ്രവും നിങ്ങളെ ക്ഷണിക്കുന്നതുപോലെ, എന്നാൽ അകത്തെ ഉപകരണം അനങ്ങാത്ത മതിലിന് മുന്നിൽ 40 ബൈറ്റ് അധികം ഉദാരമായി അവസാനിക്കുന്നു.

രണ്ട് MTU-കളും വെവ്വേറെ സജ്ജമാക്കുക

വാഹകനും ഉള്ളിൽ ഒതുക്കിയ ഉപകരണവും വെവ്വേറെ വസ്തുക്കളാണ്, അതിനാൽ ഓരോന്നിനും സ്വന്തം മൂല്യം വേണം. ഇവ ഈ ക്രമത്തിൽ പ്രയോഗിക്കുക, കാരണം ഉള്ളിൽ ഒതുക്കിയ ഉപകരണം വാഹകനിൽ നിന്ന് ഒന്നും പാരമ്പര്യമായി സ്വീകരിക്കുന്നില്ല:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

ഓർക്കാൻ യോഗ്യമായ നിയമം: ഉള്ളിലെ MTU = പുറത്തെ MTU - 20, IPIP ടണൽ വഹിക്കുന്ന പാക്കറ്റ് IPv4 ആണെങ്കിൽ, കൂടാതെ - 40, ഉള്ളിലെ പാക്കറ്റിന്റെ ഏതെങ്കിലും വശം IPv6 ആകുമ്പോൾ, കാരണം ഉള്ളിൽ ഒതുക്കിയ ഹെഡർ 20 ബൈറ്റിൽ നിന്ന് 40 ആയി വളരുന്നു. ആ കുറയ്ക്കലിൽ മറ്റൊന്നും വരുന്നില്ല. 1420 തിരഞ്ഞെടുത്തപ്പോൾ തന്നെ WireGuard-ന്റെ ഓവർഹെഡ് ചെലവഴിച്ചിരുന്നു, അത് രണ്ടുതവണ ഈടാക്കിയാൽ തികച്ചും പ്രവർത്തിക്കുന്നതും ആരും അളക്കാത്തിടത്തോളം മന്ദഗതിയിലുള്ളതുമായ ടണൽ ഉണ്ടാകുന്നു. രണ്ട് ഉപകരണങ്ങളും വൃത്താകൃതിയിലുള്ള 1400 വഹിക്കുന്ന വിന്യാസം ആ തെറ്റിന്റെ കൃത്യമായ വിരലടയാളമാണ്.

ഉള്ളിൽ ഒതുക്കിയ പാക്കറ്റിന്റെ ഏതെങ്കിലും വശത്ത് IPv6 ഉണ്ടെങ്കിൽ മുകളിലെ ഓരോ സംഖ്യയും അസാധുവാകും, അതിനാൽ സമാനമായ സൈറ്റിൽ നിന്ന് സംഖ്യ പകർത്തുന്നതിന് പകരം വീണ്ടും കണക്കാക്കുക. IPv6 പുറം പാതയിലോ യഥാർത്ഥ ഡേറ്റാഗ്രാമിലോ പ്രത്യക്ഷപ്പെടുമ്പോൾ കുറയ്ക്കുന്ന ഹെഡറുകൾ ഓരോന്നും 40 ബൈറ്റാണ്, പേലോഡ് സംഖ്യ കൃത്യമായി അത്രയും കുറയുന്നു.

നിങ്ങൾക്ക് ഒരുപക്ഷേ ആവശ്യമില്ലാത്ത ഫയർവാൾ നിയമം

രണ്ട് WireGuard പിയറുകൾക്കിടയിൽ വയറിൽ ഉള്ളത് UDP മാത്രമാണ്, അതിനാൽ പ്രോട്ടോക്കോൾ 4-നുള്ള ഇൻബൗണ്ട് നിയമം, RFC 2003 IPv4-ഇൻ-IPv4 എൻകാപ്സുലേഷന് നൽകുന്ന നമ്പർ, ഉള്ളിൽ ഒതുക്കിയ പാത സൃഷ്ടിക്കുന്നുമില്ല, അതിനെ ജീവനോടെ നിർത്തുന്നുമില്ല. IPIP ഹെഡർ എൻക്രിപ്റ്റ് ചെയ്ത പേലോഡിനുള്ളിൽ ജീവിക്കുന്നു, അവിടെ ഒരു എഡ്ജ് ഫയർവാളും അത് കാണുന്നില്ല. പ്രോട്ടോക്കോൾ 4 തുറന്നാലും ഹോസ്റ്റിലേക്ക് ഒരു അനുവദനീയ പാത കൂടി എന്നതിൽ കൂടുതൽ ഒന്നും നൽകുന്നില്ല.

യഥാർത്ഥ പാക്കറ്റിന്റെ ഉറവിടങ്ങളും ലക്ഷ്യസ്ഥാനങ്ങളും പരാമർശിക്കുന്ന നയം ഡീകാപ്സുലേഷനു ശേഷം, ടണൽ ഇന്റർഫേസുകളിലും റൂട്ടിംഗ് പട്ടികയിലും വരുന്നു. അത് അവിടെ വെക്കുക, എഡ്ജ് നിയമം അടച്ചിടാം.

WireGuard യഥാർത്ഥത്തിൽ എന്താണ് സാധൂകരിക്കുന്നത്

AllowedIPs WireGuard വഹിക്കുന്ന പാക്കറ്റിന്റെ ഉറവിടം വിധിക്കുന്നു, അത് വഹിക്കുന്നത് IPIP-എൻകാപ്സുലേറ്റ് ചെയ്ത പാക്കറ്റാണ്. അനുവദനീയമായ IPIP ഉറവിടം, ഉള്ളിലെ ഹെഡർ നിങ്ങൾ റൂട്ട് ചെയ്യാൻ ആഗ്രഹിക്കാത്ത ഒരു ഹോസ്റ്റിനെ പേരെടുത്ത് പറഞ്ഞാലും സ്വീകരിക്കപ്പെടുന്നു. അതിനാൽ യഥാർത്ഥ ഉറവിടം പിയർ നിങ്ങൾക്കുവേണ്ടി പരിശോധിച്ചതല്ല, ആ ഉള്ളിലെ വിലാസ ജോടിക്ക് ഡീകാപ്സുലേഷനു ശേഷം സ്വന്തം നിർവ്വഹണം വേണം.

റാപ്പർ റൂട്ടിംഗ് ഘടന നൽകുന്നു, രണ്ടാം ക്രിപ്റ്റോഗ്രാഫി പാളിയല്ല. WireGuard-നുള്ളിൽ IPIP-യെ അധിക സംരക്ഷണം എന്ന് വിളിക്കുന്നത് വേറെ ഒരു രൂപകൽപ്പനയെ വിവരിക്കുന്നു.

ഒരു ping അല്ല, ഒരു ഗോവണി ഉപയോഗിച്ച് പരിശോധിക്കുക

കണക്കാക്കിയ അതിർത്തിയെ ഇരുവശത്തുനിന്നും കടക്കുന്ന വലിപ്പങ്ങൾ പരിശോധിക്കുക, പിന്നീട് രണ്ട് ഉപകരണങ്ങളെക്കുറിച്ചും കേർണൽ എന്താണ് വിശ്വസിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക. 1360 ബൈറ്റ് പേലോഡും 40 ബൈറ്റ് ഹെഡറുകളും ചേർന്ന് 1400 ആകുമ്പോൾ, താഴെയുള്ള ആദ്യ പ്രതിധ്വനി ഒതുങ്ങുന്നു, രണ്ടാമത്തേത് പരമാവധി പരിധിക്ക് ഒരു ബൈറ്റ് അപ്പുറം ഇരിക്കുന്നു:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

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