ipipou: ഒരു എൻക്രിപ്റ്റ് ചെയ്യാത്ത തുരങ്കം മാത്രമല്ല

IPv6-ലെ ദൈവത്തോട് നമ്മൾ എന്താണ് പറയുന്നത്?

അത് ശരിയാണ്, ഇന്ന് നമ്മൾ എൻക്രിപ്ഷൻ ദൈവത്തോടും പറയും.

ഇവിടെ നമ്മൾ ഒരു എൻക്രിപ്റ്റ് ചെയ്യാത്ത IPv4 ടണലിനെ കുറിച്ച് സംസാരിക്കും, എന്നാൽ "ഊഷ്മള വിളക്ക്" ഒന്നിനെ കുറിച്ചല്ല, മറിച്ച് ഒരു ആധുനിക "LED" ഒന്നിനെ കുറിച്ചാണ്. കൂടാതെ ഇവിടെ റോ സോക്കറ്റുകൾ മിന്നിമറയുന്നു, കൂടാതെ ഉപയോക്തൃ സ്ഥലത്ത് പാക്കറ്റുകൾ ഉപയോഗിച്ച് ജോലികൾ നടക്കുന്നു.

ഓരോ രുചിക്കും നിറത്തിനും N ടണലിംഗ് പ്രോട്ടോക്കോളുകൾ ഉണ്ട്:

• സ്റ്റൈലിഷ്, ഫാഷൻ, യുവത്വം WireGuard
• സ്വിസ് കത്തികൾ, OpenVPN, SSH എന്നിവ പോലെ മൾട്ടിഫങ്ഷണൽ
• പഴയതും തിന്മയല്ലാത്തതുമായ GRE
• ഏറ്റവും ലളിതവും വേഗതയേറിയതും പൂർണ്ണമായും എൻക്രിപ്റ്റ് ചെയ്യാത്തതുമായ IPIP
• സജീവമായി വികസിക്കുന്നു ജനീവ്
• മറ്റു പലരും.

എന്നാൽ ഞാൻ ഒരു പ്രോഗ്രാമറാണ്, അതിനാൽ ഞാൻ N ഒരു ഭിന്നസംഖ്യ കൊണ്ട് വർദ്ധിപ്പിക്കും, കൂടാതെ യഥാർത്ഥ പ്രോട്ടോക്കോളുകളുടെ വികസനം കൊമ്മേഴ്‌സന്റ് ഡെവലപ്പർമാർക്ക് വിട്ടുകൊടുക്കും.

ഒരു അജാതയിൽ പദ്ധതിഞാൻ ഇപ്പോൾ ചെയ്യുന്നത് പുറത്ത് നിന്ന് NAT-ന് പിന്നിലുള്ള ഹോസ്റ്റുകളിൽ എത്തിച്ചേരുക എന്നതാണ്. മുതിർന്നവർക്കുള്ള ക്രിപ്‌റ്റോഗ്രാഫി ഉള്ള പ്രോട്ടോക്കോളുകൾ ഇതിനായി ഉപയോഗിക്കുമ്പോൾ, ഇത് പീരങ്കിയിൽ നിന്ന് കുരുവികളെ എറിയുന്നത് പോലെയാണെന്ന തോന്നൽ എനിക്ക് ഇളകാൻ കഴിഞ്ഞില്ല. കാരണം തുരങ്കം ഭൂരിഭാഗവും ഉപയോഗിക്കുന്നത് NAT-e-യിൽ ദ്വാരങ്ങൾ ഉണ്ടാക്കാൻ മാത്രമാണ്, ആന്തരിക ട്രാഫിക്കും സാധാരണയായി എൻക്രിപ്റ്റ് ചെയ്യപ്പെടുന്നു, പക്ഷേ അവ ഇപ്പോഴും HTTPS-ൽ മുങ്ങിമരിക്കുന്നു.

വിവിധ ടണലിംഗ് പ്രോട്ടോക്കോളുകൾ ഗവേഷണം ചെയ്യുമ്പോൾ, എന്റെ ആന്തരിക പെർഫെക്ഷനിസ്റ്റിന്റെ ശ്രദ്ധ ഐപിഐപിയിലേക്ക് അതിന്റെ ഏറ്റവും കുറഞ്ഞ ഓവർഹെഡ് കാരണം വീണ്ടും വീണ്ടും ആകർഷിക്കപ്പെട്ടു. എന്നാൽ എന്റെ ജോലികൾക്ക് ഇതിന് ഒന്നര കാര്യമായ പോരായ്മകളുണ്ട്:

• ഇതിന് ഇരുവശത്തും പൊതു ഐപികൾ ആവശ്യമാണ്,
• നിങ്ങൾക്ക് ആധികാരികതയില്ല.

അതിനാൽ, പൂർണതയുള്ളവനെ തലയോട്ടിയുടെ ഇരുണ്ട മൂലയിലേക്കോ അല്ലെങ്കിൽ അവൻ അവിടെ ഇരിക്കുന്നിടത്തിലേക്കോ തിരികെ ഓടിച്ചു.

പിന്നെ ഒരു ദിവസം, ലേഖനങ്ങൾ വായിക്കുമ്പോൾ തദ്ദേശീയമായി പിന്തുണയ്ക്കുന്ന തുരങ്കങ്ങൾ Linux-ൽ ഞാൻ FOU (Foo-over-UDP) കണ്ടു, അതായത്. എന്തുതന്നെയായാലും, UDP-യിൽ പൊതിഞ്ഞ്. ഇതുവരെ, IPIP, GUE (ജനറിക് UDP എൻക്യാപ്‌സുലേഷൻ) എന്നിവ മാത്രമേ പിന്തുണയ്ക്കുന്നുള്ളൂ.

“ഇതാ വെള്ളി ബുള്ളറ്റ്! എനിക്ക് ഒരു ലളിതമായ IPIP മതി.” - ഞാൻ വിചാരിച്ചു.

വാസ്തവത്തിൽ, ബുള്ളറ്റ് പൂർണ്ണമായും വെള്ളിയല്ലെന്ന് തെളിഞ്ഞു. യു‌ഡി‌പിയിലെ എൻ‌ക്യാപ്‌സുലേഷൻ‌ ആദ്യത്തെ പ്രശ്‌നം പരിഹരിക്കുന്നു - മുൻകൂട്ടി സ്ഥാപിതമായ ഒരു കണക്ഷൻ ഉപയോഗിച്ച് നിങ്ങൾക്ക് പുറത്ത് നിന്ന് NAT-ന് പിന്നിലെ ക്ലയന്റുകളിലേക്ക് കണക്റ്റുചെയ്യാനാകും, എന്നാൽ ഇവിടെ IPIP- യുടെ അടുത്ത പോരായ്മയുടെ പകുതിയും പുതിയ വെളിച്ചത്തിൽ പൂക്കുന്നു - ഒരു സ്വകാര്യ നെറ്റ്‌വർക്കിൽ നിന്നുള്ള ആർക്കും ദൃശ്യത്തിന് പിന്നിൽ മറയ്ക്കാൻ കഴിയും. പൊതു ഐപിയും ക്ലയന്റ് പോർട്ടും (ശുദ്ധമായ ഐപിഐപിയിൽ ഈ പ്രശ്നം നിലവിലില്ല).

ഈ ഒന്നര പ്രശ്നം പരിഹരിക്കാൻ, യൂട്ടിലിറ്റി പിറന്നു ipipou. കേർണൽ FOU-യുടെ പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്താതെ, ഒരു റിമോട്ട് ഹോസ്റ്റ് ആധികാരികമാക്കുന്നതിനുള്ള ഒരു ഹോം-മെയ്ഡ് മെക്കാനിസം ഇത് നടപ്പിലാക്കുന്നു, ഇത് കേർണൽ സ്പേസിൽ പാക്കറ്റുകൾ വേഗത്തിലും കാര്യക്ഷമമായും പ്രോസസ്സ് ചെയ്യും.

ഞങ്ങൾക്ക് നിങ്ങളുടെ സ്ക്രിപ്റ്റ് ആവശ്യമില്ല!

ശരി, ക്ലയന്റിന്റെ പൊതു പോർട്ടും IP-യും നിങ്ങൾക്ക് അറിയാമെങ്കിൽ (ഉദാഹരണത്തിന്, ഇതിന് പിന്നിലുള്ള എല്ലാവരും എവിടെയും പോകുന്നില്ല, NAT 1-ഇൻ-1 പോർട്ടുകൾ മാപ്പ് ചെയ്യാൻ ശ്രമിക്കുന്നു), നിങ്ങൾക്ക് ഒരു IPIP-over-FOU ടണൽ സൃഷ്ടിക്കാൻ കഴിയും സ്ക്രിപ്റ്റുകളൊന്നുമില്ലാതെ താഴെ പറയുന്ന കമാൻഡുകൾ.

സെർവറിൽ:

# Подгрузить модуль ядра FOU
modprobe fou

# Создать IPIP туннель с инкапсуляцией в FOU.
# Модуль ipip подгрузится автоматически.
ip link add name ipipou0 type ipip 
    remote 198.51.100.2 local 203.0.113.1 
    encap fou encap-sport 10000 encap-dport 20001 
    mode ipip dev eth0

# Добавить порт на котором будет слушать FOU для этого туннеля
ip fou add port 10000 ipproto 4 local 203.0.113.1 dev eth0

# Назначить IP адрес туннелю
ip address add 172.28.0.0 peer 172.28.0.1 dev ipipou0

# Поднять туннель
ip link set ipipou0 up

ക്ലയന്റിൽ:

modprobe fou

ip link add name ipipou1 type ipip 
    remote 203.0.113.1 local 192.168.0.2 
    encap fou encap-sport 10001 encap-dport 10000 encap-csum 
    mode ipip dev eth0

# Опции local, peer, peer_port, dev могут не поддерживаться старыми ядрами, можно их опустить.
# peer и peer_port используются для создания соединения сразу при создании FOU-listener-а.
ip fou add port 10001 ipproto 4 local 192.168.0.2 peer 203.0.113.1 peer_port 10000 dev eth0

ip address add 172.28.0.1 peer 172.28.0.0 dev ipipou1

ip link set ipipou1 up

എവിടെ

• ipipou* - ലോക്കൽ ടണൽ നെറ്റ്‌വർക്ക് ഇന്റർഫേസിന്റെ പേര്
• 203.0.113.1 - പൊതു ഐപി സെർവർ
• 198.51.100.2 - ക്ലയന്റിന്റെ പൊതു ഐ.പി
• 192.168.0.2 — eth0 എന്ന ഇന്റർഫേസിലേക്ക് ക്ലയന്റ് ഐപി അസൈൻ ചെയ്‌തിരിക്കുന്നു
• 10001 - FOU നായുള്ള പ്രാദേശിക ക്ലയന്റ് പോർട്ട്
• 20001 - FOU-നുള്ള പൊതു ക്ലയന്റ് പോർട്ട്
• 10000 - FOU-നുള്ള പൊതു സെർവർ പോർട്ട്
• encap-csum — എൻക്യാപ്‌സുലേറ്റ് ചെയ്‌ത UDP പാക്കറ്റുകളിലേക്ക് ഒരു UDP ചെക്ക്‌സം ചേർക്കുന്നതിനുള്ള ഓപ്ഷൻ; ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കാം noencap-csum, പറയേണ്ടതില്ലല്ലോ, സമഗ്രത ഇതിനകം തന്നെ ബാഹ്യ എൻക്യാപ്‌സുലേഷൻ പാളിയാൽ നിയന്ത്രിക്കപ്പെടുന്നു (പാക്കറ്റ് തുരങ്കത്തിനുള്ളിലായിരിക്കുമ്പോൾ)
• eth0 — ipip ടണൽ ബന്ധിപ്പിച്ചിരിക്കുന്ന പ്രാദേശിക ഇന്റർഫേസ്
• 172.28.0.1 — ക്ലയന്റ് ടണൽ ഇന്റർഫേസിന്റെ IP (സ്വകാര്യം)
• 172.28.0.0 — IP ടണൽ സെർവർ ഇന്റർഫേസ് (സ്വകാര്യം)

UDP കണക്ഷൻ സജീവമായിരിക്കുന്നിടത്തോളം, തുരങ്കം പ്രവർത്തന ക്രമത്തിലായിരിക്കും, പക്ഷേ അത് തകർന്നാൽ, നിങ്ങൾ ഭാഗ്യവാനാണ് - ക്ലയന്റിന്റെ IP: പോർട്ട് അതേപടി തുടരുകയാണെങ്കിൽ - അത് ജീവിക്കും, അവ മാറുകയാണെങ്കിൽ - അത് തകരും.

കേർണൽ മൊഡ്യൂളുകൾ അൺലോഡ് ചെയ്യുക എന്നതാണ് എല്ലാം തിരികെ കൊണ്ടുവരാനുള്ള എളുപ്പവഴി: modprobe -r fou ipip

പ്രാമാണീകരണം ആവശ്യമില്ലെങ്കിൽപ്പോലും, ക്ലയന്റിന്റെ പൊതു ഐപിയും പോർട്ടും എല്ലായ്പ്പോഴും അറിയപ്പെടില്ല, അവ പലപ്പോഴും പ്രവചനാതീതമോ വേരിയബിളോ ആയിരിക്കും (NAT തരത്തെ ആശ്രയിച്ച്). നിങ്ങൾ ഒഴിവാക്കുകയാണെങ്കിൽ encap-dport സെർവർ വശത്ത്, ടണൽ പ്രവർത്തിക്കില്ല, റിമോട്ട് കണക്ഷൻ പോർട്ട് എടുക്കാൻ ഇത് വേണ്ടത്ര സ്മാർട്ടല്ല. ഈ സാഹചര്യത്തിൽ, ipipou-യ്‌ക്കും സഹായിക്കാനാകും, അല്ലെങ്കിൽ WireGuard-നും അതുപോലുള്ള മറ്റുള്ളവർക്കും നിങ്ങളെ സഹായിക്കാനാകും.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു?

ക്ലയന്റ് (സാധാരണയായി NAT ന് പിന്നിലാണ്) ഒരു തുരങ്കം തുറക്കുന്നു (മുകളിലുള്ള ഉദാഹരണത്തിലെന്നപോലെ), സെർവറിലേക്ക് ഒരു ആധികാരികത പാക്കറ്റ് അയയ്‌ക്കുന്നു, അങ്ങനെ അത് അതിന്റെ വശത്ത് ടണൽ കോൺഫിഗർ ചെയ്യുന്നു. ക്രമീകരണങ്ങളെ ആശ്രയിച്ച്, ഇത് ഒരു ശൂന്യമായ പാക്കറ്റ് ആകാം (സെർവറിന് പൊതു ഐപി: കണക്ഷൻ പോർട്ട് കാണാനാകുന്ന തരത്തിൽ), അല്ലെങ്കിൽ സെർവറിന് ക്ലയന്റിനെ തിരിച്ചറിയാൻ കഴിയുന്ന ഡാറ്റ ഉപയോഗിച്ച്. ഡാറ്റ വ്യക്തമായ ടെക്‌സ്‌റ്റിലുള്ള ഒരു ലളിതമായ പാസ്‌ഫ്രെയ്‌സ് ആകാം (HTTP ബേസിക് ഓത്തുമായുള്ള സാമ്യം മനസ്സിൽ വരുന്നത്) അല്ലെങ്കിൽ ഒരു സ്വകാര്യ കീ ഉപയോഗിച്ച് സൈൻ ചെയ്‌ത പ്രത്യേകം രൂപകൽപ്പന ചെയ്‌ത ഡാറ്റ (HTTP Digest Auth-ന് സമാനമായി കൂടുതൽ ശക്തമാണ്, പ്രവർത്തനം കാണുക. client_auth കോഡിൽ).

സെർവറിൽ (പബ്ലിക് ഐപി ഉള്ള വശം), ipipou ആരംഭിക്കുമ്പോൾ, അത് ഒരു nfqueue ക്യൂ ഹാൻഡ്‌ലർ സൃഷ്‌ടിക്കുകയും നെറ്റ്ഫിൽട്ടർ കോൺഫിഗർ ചെയ്യുകയും ചെയ്യുന്നു, അങ്ങനെ ആവശ്യമായ പാക്കറ്റുകൾ അവ എവിടെയായിരിക്കണമെന്ന് അയയ്‌ക്കും: nfqueue ക്യൂവിലേക്കുള്ള കണക്ഷൻ ആരംഭിക്കുന്ന പാക്കറ്റുകൾ, കൂടാതെ [ഏതാണ്ട്] ബാക്കിയെല്ലാം ശ്രോതാവായ FOU-ലേക്ക് നേരിട്ട് പോകുന്നു.

അറിയാത്തവർക്ക്, കേർണൽ മൊഡ്യൂളുകൾ എങ്ങനെ വികസിപ്പിക്കണമെന്ന് അറിയാത്ത അമച്വർമാർക്ക് nfqueue (അല്ലെങ്കിൽ NetfilterQueue) ഒരു പ്രത്യേക കാര്യമാണ്, ഇത് നെറ്റ്ഫിൽറ്റർ (nftables/iptables) ഉപയോഗിച്ച് നെറ്റ്‌വർക്ക് പാക്കറ്റുകൾ ഉപയോക്തൃ സ്ഥലത്തേക്ക് റീഡയറക്‌ട് ചെയ്യാനും അവ ഉപയോഗിച്ച് പ്രോസസ്സ് ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു. പ്രാകൃത മാർഗങ്ങൾ കൈയിലുണ്ട്: പരിഷ്ക്കരിക്കുക (ഓപ്ഷണൽ ) അത് കേർണലിലേക്ക് തിരികെ നൽകുക, അല്ലെങ്കിൽ ഉപേക്ഷിക്കുക.

ചില പ്രോഗ്രാമിംഗ് ഭാഷകൾക്ക് nfqueue-മായി പ്രവർത്തിക്കുന്നതിന് ബൈൻഡിംഗുകൾ ഉണ്ട്, ബാഷിന് ഒന്നുമില്ല (ഹേ, അതിശയിക്കാനില്ല), എനിക്ക് പൈത്തൺ ഉപയോഗിക്കേണ്ടി വന്നു: ipipou ഉപയോഗിക്കുന്നു നെറ്റ്ഫിൽറ്റർ ക്യൂ.

പ്രകടനം നിർണായകമല്ലെങ്കിൽ, ഈ കാര്യം ഉപയോഗിച്ച് നിങ്ങൾക്ക് താരതമ്യേന വേഗത്തിലും എളുപ്പത്തിലും നിങ്ങളുടെ സ്വന്തം ലോജിക്ക് വളരെ താഴ്ന്ന തലത്തിൽ പാക്കറ്റുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, പരീക്ഷണാത്മക ഡാറ്റാ ട്രാൻസ്ഫർ പ്രോട്ടോക്കോളുകൾ സൃഷ്ടിക്കുക, അല്ലെങ്കിൽ നിലവാരമില്ലാത്ത പെരുമാറ്റം ഉപയോഗിച്ച് ലോക്കൽ, റിമോട്ട് സേവനങ്ങൾ ട്രോൾ ചെയ്യുക.

റോ സോക്കറ്റുകൾ nfqueue-മായി കൈകോർത്ത് പ്രവർത്തിക്കുന്നു, ഉദാഹരണത്തിന്, ടണൽ ഇതിനകം കോൺഫിഗർ ചെയ്‌തിരിക്കുമ്പോൾ, ആവശ്യമുള്ള പോർട്ടിൽ FOU കേൾക്കുമ്പോൾ, നിങ്ങൾക്ക് അതേ പോർട്ടിൽ നിന്ന് സാധാരണ രീതിയിൽ ഒരു പാക്കറ്റ് അയയ്ക്കാൻ കഴിയില്ല - ഇത് തിരക്കിലാണ്, പക്ഷേ ഒരു റോ സോക്കറ്റ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ക്രമരഹിതമായി ജനറേറ്റുചെയ്‌ത ഒരു പാക്കറ്റ് നേരിട്ട് നെറ്റ്‌വർക്ക് ഇന്റർഫേസിലേക്ക് അയയ്ക്കാനും അയയ്ക്കാനും കഴിയും, എന്നിരുന്നാലും അത്തരമൊരു പാക്കറ്റ് നിർമ്മിക്കുന്നതിന് കുറച്ച് കൂടി ടിങ്കറിംഗ് ആവശ്യമാണ്. ipipou-ൽ ആധികാരികതയുള്ള പാക്കറ്റുകൾ സൃഷ്ടിക്കുന്നത് ഇങ്ങനെയാണ്.

കണക്ഷനിൽ നിന്നുള്ള ആദ്യത്തെ പാക്കറ്റുകൾ മാത്രമേ ipipou പ്രോസസ്സ് ചെയ്യുന്നുള്ളൂ എന്നതിനാൽ (കൂടാതെ കണക്ഷൻ സ്ഥാപിക്കുന്നതിന് മുമ്പ് ക്യൂവിലേക്ക് ചോർത്താൻ കഴിഞ്ഞവ), പ്രകടനം മിക്കവാറും ബാധിക്കില്ല.

ipipou സെർവറിന് ഒരു ആധികാരിക പാക്കറ്റ് ലഭിച്ചാലുടൻ, ഒരു ടണൽ സൃഷ്ടിക്കപ്പെടുന്നു, കൂടാതെ കണക്ഷനിലെ എല്ലാ തുടർന്നുള്ള പാക്കറ്റുകളും ഇതിനകം തന്നെ nfqueue ബൈപാസ് ചെയ്യുന്ന കേർണൽ വഴി പ്രോസസ്സ് ചെയ്യുന്നു. കണക്ഷൻ പരാജയപ്പെടുകയാണെങ്കിൽ, ക്രമീകരണങ്ങളെ ആശ്രയിച്ച്, അടുത്തതിന്റെ ആദ്യ പാക്കറ്റ് nfqueue ക്യൂവിലേക്ക് അയയ്ക്കും, ഇത് പ്രാമാണീകരണമുള്ള ഒരു പാക്കറ്റല്ലെങ്കിൽ, അവസാനമായി ഓർമ്മിച്ച IP, ക്ലയന്റ് പോർട്ട് എന്നിവയിൽ നിന്ന്, ഒന്നുകിൽ അത് കൈമാറാൻ കഴിയും. ഓൺ അല്ലെങ്കിൽ ഉപേക്ഷിച്ചു. ഒരു പുതിയ ഐപിയിൽ നിന്നും പോർട്ടിൽ നിന്നുമാണ് ഒരു ആധികാരിക പാക്കറ്റ് വരുന്നതെങ്കിൽ, അവ ഉപയോഗിക്കുന്നതിനായി ടണൽ വീണ്ടും ക്രമീകരിച്ചിരിക്കുന്നു.

NAT-ൽ പ്രവർത്തിക്കുമ്പോൾ സാധാരണ IPIP-over-FOU-ന് ഒരു പ്രശ്നം കൂടിയുണ്ട് - ഒരേ IP ഉപയോഗിച്ച് UDP-യിൽ പൊതിഞ്ഞ രണ്ട് IPIP ടണലുകൾ സൃഷ്ടിക്കുന്നത് അസാധ്യമാണ്, കാരണം FOU, IPIP മൊഡ്യൂളുകൾ പരസ്പരം തികച്ചും ഒറ്റപ്പെട്ടതാണ്. ആ. ഒരേ പബ്ലിക് ഐപിക്ക് പിന്നിലുള്ള ഒരു ജോടി ക്ലയന്റുകൾക്ക് ഒരേ സെർവറിലേക്ക് ഈ രീതിയിൽ ഒരേസമയം കണക്റ്റുചെയ്യാൻ കഴിയില്ല. ഭാവിയിൽ, ഒരുപക്ഷേ, ഇത് കേർണൽ തലത്തിൽ പരിഹരിക്കപ്പെടും, പക്ഷേ ഇത് ഉറപ്പില്ല. ഇതിനിടയിൽ, NAT പ്രശ്‌നങ്ങൾ NAT-ന് പരിഹരിക്കാൻ കഴിയും - ഒരു ജോടി IP വിലാസങ്ങൾ ഇതിനകം മറ്റൊരു ടണൽ കൈവശപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ, ipipou പൊതുജനങ്ങളിൽ നിന്ന് ഒരു ഇതര സ്വകാര്യ IP-ലേക്ക് NAT ചെയ്യും, voila! - പോർട്ടുകൾ തീരുന്നതുവരെ നിങ്ങൾക്ക് തുരങ്കങ്ങൾ സൃഷ്ടിക്കാൻ കഴിയും.

കാരണം കണക്ഷനിലെ എല്ലാ പാക്കറ്റുകളും ഒപ്പിട്ടിട്ടില്ല, അപ്പോൾ ഈ ലളിതമായ സംരക്ഷണം MITM-ന് അപകടകരമാണ്, അതിനാൽ ക്ലയന്റിനും സെർവറിനും ഇടയിലുള്ള പാതയിൽ പതിയിരിക്കുന്ന ഒരു വില്ലൻ ഉണ്ടെങ്കിൽ, അയാൾക്ക് ആധികാരികമായ പാക്കറ്റുകൾ വഴി തിരിച്ചുവിടാൻ കഴിയും. മറ്റൊരു വിലാസം കൂടാതെ വിശ്വസനീയമല്ലാത്ത ഒരു ഹോസ്റ്റിൽ നിന്ന് ഒരു തുരങ്കം സൃഷ്ടിക്കുക.

കാമ്പിലെ ട്രാഫിക്കിന്റെ ഭൂരിഭാഗവും ഉപേക്ഷിക്കുമ്പോൾ ഇത് എങ്ങനെ പരിഹരിക്കാമെന്ന് ആർക്കെങ്കിലും ആശയങ്ങളുണ്ടെങ്കിൽ, സംസാരിക്കാൻ മടിക്കരുത്.

വഴിയിൽ, യു‌ഡി‌പിയിലെ എൻ‌കാപ്‌സുലേഷൻ സ്വയം നന്നായി തെളിയിച്ചിട്ടുണ്ട്. ഐപിയിലെ എൻക്യാപ്‌സുലേഷനുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ, യുഡിപി ഹെഡറിന്റെ അധിക ഓവർഹെഡ് ഉണ്ടായിരുന്നിട്ടും ഇത് കൂടുതൽ സ്ഥിരതയുള്ളതും പലപ്പോഴും വേഗതയുള്ളതുമാണ്. ഇന്റർനെറ്റിലെ മിക്ക ഹോസ്റ്റുകളും ഏറ്റവും ജനപ്രിയമായ മൂന്ന് പ്രോട്ടോക്കോളുകൾ ഉപയോഗിച്ച് മാത്രം നന്നായി പ്രവർത്തിക്കുന്നു എന്നതാണ് ഇതിന് കാരണം: TCP, UDP, ICMP. മൂർത്തമായ ഭാഗത്തിന് മറ്റെല്ലാം പൂർണ്ണമായി നിരസിക്കാനോ അല്ലെങ്കിൽ കൂടുതൽ സാവധാനത്തിൽ പ്രോസസ്സ് ചെയ്യാനോ കഴിയും, കാരണം ഇത് ഈ മൂന്നിന് മാത്രം ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു.

ഉദാഹരണത്തിന്, ഇതുകൊണ്ടാണ് എച്ച്ടിടിപി/3 അടിസ്ഥാനമാക്കിയുള്ള ക്വിക്ക്, യുഡിപിയുടെ മുകളിലാണ് സൃഷ്ടിച്ചത്, ഐപിയുടെ മുകളിലല്ല.

ശരി, മതിയായ വാക്കുകൾ, "യഥാർത്ഥ ലോകത്ത്" ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാനുള്ള സമയമാണിത്.

യുദ്ധം

യഥാർത്ഥ ലോകത്തെ അനുകരിക്കാൻ ഉപയോഗിക്കുന്നു iperf3. യാഥാർത്ഥ്യത്തോടുള്ള അടുപ്പത്തിന്റെ കാര്യത്തിൽ, ഇത് Minecraft-ലെ യഥാർത്ഥ ലോകത്തെ അനുകരിക്കുന്നതിന് ഏകദേശം തുല്യമാണ്, എന്നാൽ ഇപ്പോൾ അത് ചെയ്യും.

മത്സരത്തിൽ പങ്കെടുക്കുന്നവർ:

• റഫറൻസ് പ്രധാന ചാനൽ
• ഈ ലേഖനത്തിലെ നായകൻ ipipou ആണ്
• ഓതന്റിക്കേഷനോടുകൂടിയ OpenVPN എന്നാൽ എൻക്രിപ്ഷൻ ഇല്ല
• എല്ലാം ഉൾക്കൊള്ളുന്ന മോഡിൽ OpenVPN
• PresharedKey ഇല്ലാതെ വയർഗാർഡ്, MTU=1440 ഉള്ളത് (IPv4-മാത്രം മുതൽ)

ഗീക്കുകൾക്കുള്ള സാങ്കേതിക ഡാറ്റ
ഇനിപ്പറയുന്ന കമാൻഡുകൾ ഉപയോഗിച്ച് മെട്രിക്സ് എടുക്കുന്നു:

ക്ലയന്റിൽ:

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2 -u -b 12M; tail -1 "$CPULOG"
# Где "-b 12M" это пропускная способность основного канала, делённая на число потоков "-P", чтобы лишние пакеты не плодить и не портить производительность.

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -c SERVER_IP -4 -t 60 -f m -i 10 -B LOCAL_IP -P 2; tail -1 "$CPULOG"

ICMP ലേറ്റൻസി

ping -c 10 SERVER_IP | tail -1

സെർവറിൽ (ക്ലയന്റുമായി ഒരേസമയം പ്രവർത്തിക്കുന്നു):

UDP

CPULOG=NAME.udp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

TCP

CPULOG=NAME.tcp.cpu.log; sar 10 6 >"$CPULOG" & iperf3 -s -i 10 -f m -1; tail -1 "$CPULOG"

ടണൽ കോൺഫിഗറേഷൻ

ipipou
സെർവർ
/etc/ipipou/server.conf:

server
number 0
fou-dev eth0
fou-local-port 10000
tunl-ip 172.28.0.0
auth-remote-pubkey-b64 eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-secret topsecret
auth-lifetime 3600
reply-on-auth-ok
verb 3

systemctl start ipipou@server

ഉപഭോക്താവ്
/etc/ipipou/client.conf:

client
number 0
fou-local @eth0
fou-remote SERVER_IP:10000
tunl-ip 172.28.0.1
# pubkey of auth-key-b64: eQYNhD/Xwl6Zaq+z3QXDzNI77x8CEKqY1n5kt9bKeEI=
auth-key-b64 RuBZkT23na2Q4QH1xfmZCfRgSgPt5s362UPAFbecTso=
auth-secret topsecret
keepalive 27
verb 3

systemctl start ipipou@client

openvpn (എൻക്രിപ്ഷൻ ഇല്ല, ആധികാരികതയോടെ)
സെർവർ

openvpn --genkey --secret ovpn.key  # Затем надо передать ovpn.key клиенту
openvpn --dev tun1 --local SERVER_IP --port 2000 --ifconfig 172.16.17.1 172.16.17.2 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

ഉപഭോക്താവ്

openvpn --dev tun1 --local LOCAL_IP --remote SERVER_IP --port 2000 --ifconfig 172.16.17.2 172.16.17.1 --cipher none --auth SHA1 --ncp-disable --secret ovpn.key

openvpn (എൻക്രിപ്ഷൻ, ആധികാരികത, UDP വഴി, എല്ലാം പ്രതീക്ഷിച്ചതുപോലെ)
ഉപയോഗിച്ച് ക്രമീകരിച്ചത് openvpn-മാനേജ് ചെയ്യുക

വയർഗാർഡ്
സെർവർ
/etc/wireguard/server.conf:

[Interface]
Address=172.31.192.1/18
ListenPort=51820
PrivateKey=aMAG31yjt85zsVC5hn5jMskuFdF8C/LFSRYnhRGSKUQ=
MTU=1440

[Peer]
PublicKey=LyhhEIjVQPVmr/sJNdSRqTjxibsfDZ15sDuhvAQ3hVM=
AllowedIPs=172.31.192.2/32

systemctl start wg-quick@server

ഉപഭോക്താവ്
/etc/wireguard/client.conf:

[Interface]
Address=172.31.192.2/18
PrivateKey=uCluH7q2Hip5lLRSsVHc38nGKUGpZIUwGO/7k+6Ye3I=
MTU=1440

[Peer]
PublicKey=DjJRmGvhl6DWuSf1fldxNRBvqa701c0Sc7OpRr4gPXk=
AllowedIPs=172.31.192.1/32
Endpoint=SERVER_IP:51820

systemctl start wg-quick@client

ഫലങ്ങൾ

നനഞ്ഞ വൃത്തികെട്ട അടയാളം
സെർവർ സിപിയു ലോഡ് വളരെ സൂചകമല്ല, കാരണം... മറ്റ് നിരവധി സേവനങ്ങൾ അവിടെ പ്രവർത്തിക്കുന്നു, ചിലപ്പോൾ അവർ വിഭവങ്ങൾ തിന്നുന്നു:

proto bandwidth[Mbps] CPU_idle_client[%] CPU_idle_server[%]
# 20 Mbps канал с микрокомпьютера (4 core) до VPS (1 core) через Атлантику
# pure
UDP 20.4      99.80 93.34
TCP 19.2      99.67 96.68
ICMP latency min/avg/max/mdev = 198.838/198.997/199.360/0.372 ms
# ipipou
UDP 19.8      98.45 99.47
TCP 18.8      99.56 96.75
ICMP latency min/avg/max/mdev = 199.562/208.919/220.222/7.905 ms
# openvpn0 (auth only, no encryption)
UDP 19.3      99.89 72.90
TCP 16.1      95.95 88.46
ICMP latency min/avg/max/mdev = 191.631/193.538/198.724/2.520 ms
# openvpn (full encryption, auth, etc)
UDP 19.6      99.75 72.35
TCP 17.0      94.47 87.99
ICMP latency min/avg/max/mdev = 202.168/202.377/202.900/0.451 ms
# wireguard
UDP 19.3      91.60 94.78
TCP 17.2      96.76 92.87
ICMP latency min/avg/max/mdev = 217.925/223.601/230.696/3.266 ms

## около-1Gbps канал между VPS Европы и США (1 core)
# pure
UDP 729      73.40 39.93
TCP 363      96.95 90.40
ICMP latency min/avg/max/mdev = 106.867/106.994/107.126/0.066 ms
# ipipou
UDP 714      63.10 23.53
TCP 431      95.65 64.56
ICMP latency min/avg/max/mdev = 107.444/107.523/107.648/0.058 ms
# openvpn0 (auth only, no encryption)
UDP 193      17.51  1.62
TCP  12      95.45 92.80
ICMP latency min/avg/max/mdev = 107.191/107.334/107.559/0.116 ms
# wireguard
UDP 629      22.26  2.62
TCP 198      77.40 55.98
ICMP latency min/avg/max/mdev = 107.616/107.788/108.038/0.128 ms

20 Mbps ചാനൽ

ഓരോ 1 ശുഭാപ്തിവിശ്വാസമുള്ള Gbps ചാനൽ

എല്ലാ സാഹചര്യങ്ങളിലും, അടിസ്ഥാന ചാനലിന്റെ പ്രകടനത്തിൽ ipipou വളരെ അടുത്താണ്, അത് മികച്ചതാണ്!

എൻക്രിപ്റ്റ് ചെയ്യാത്ത openvpn ടണൽ രണ്ട് സാഹചര്യങ്ങളിലും വളരെ വിചിത്രമായി പെരുമാറി.

ആരെങ്കിലും ഇത് പരീക്ഷിക്കാൻ പോകുകയാണെങ്കിൽ, പ്രതികരണം കേൾക്കുന്നത് രസകരമായിരിക്കും.

IPv6 ഉം NetPrickle ഉം ഞങ്ങളോടൊപ്പം ഉണ്ടാകട്ടെ!

അവലംബം: www.habr.com