ipipou: සංකේතනය නොකළ උමඟකට වඩා වැඩි යමක්

IPv6 දෙවියන්ට අපි මොනවද කියන්නේ?

ඒක හරි, අපි අද ගුප්තකේතන දෙවියන්ටත් ඒකම කියන්නම්.

මෙහිදී අපි සංකේතනය නොකළ IPv4 උමගක් ගැන කතා කරමු, නමුත් "උණුසුම් ලාම්පුවක්" ගැන නොව නවීන "LED" එකක් ගැන. තවද මෙහි අමු සොකට් දිලිසෙන අතර, පරිශීලක අවකාශයේ පැකට් සමඟ වැඩ සිදු වෙමින් පවතී.

සෑම රසය සහ වර්ණය සඳහාම N උමං ප්‍රොටෝකෝල ඇත:

• හැඩකාර, විලාසිතාමය, තරුණ වයිර්ගාර්ඩ්
• ස්විස් පිහි, OpenVPN සහ SSH වැනි බහුකාර්ය
• පැරණි සහ නරක නොවන GRE
• වඩාත්ම සරල, වේගවත්, සම්පූර්ණයෙන්ම සංකේතනය නොකළ IPIP
• ක්රියාකාරීව සංවර්ධනය වෙමින් පවතී ජිනීවා
• තවත් බොහෝ අය.

නමුත් මම ක්‍රමලේඛකයෙක්, එබැවින් මම N කොටසකින් පමණක් වැඩි කරමි, සහ සැබෑ ප්‍රොටෝකෝල සංවර්ධනය කිරීම Kommersant සංවර්ධකයින්ට භාර දෙන්නෙමි.

නූපන් එකක ව්යාපෘතියමම දැන් කරන්නේ පිටත සිට NAT පිටුපසින් සත්කාරක වෙත ළඟා වීමයි. මේ සඳහා වැඩිහිටි ගුප්තකේතනය සහිත ප්‍රොටෝකෝල භාවිතා කිරීමෙන්, එය කාලතුවක්කුවකින් ගේ කුරුල්ලන්ට වෙඩි තැබීම වැනි හැඟීමක් මට සොලවන්නට නොහැකි විය. නිසා උමග බොහෝ දුරට NAT-e හි සිදුරු කිරීමට පමණක් භාවිතා කරයි, අභ්‍යන්තර ගමනාගමනය සාමාන්‍යයෙන් සංකේතනය කර ඇත, නමුත් ඒවා තවමත් HTTPS හි ගිලී යයි.

විවිධ උමං ප්‍රොටෝකෝල ගැන පර්යේෂණ කරන අතරතුර, මගේ අභ්‍යන්තර පරිපූර්‍ණවාදියාගේ අවධානය IPIP වෙත නැවත නැවතත් යොමු වූයේ එහි අවම පොදු කාර්ය නිසා ය. නමුත් එය මගේ කාර්යයන් සඳහා සැලකිය යුතු අඩුපාඩු එකහමාරක් ඇත:

• එයට දෙපැත්තේම පොදු IP අවශ්‍ය වේ,
• සහ ඔබ සඳහා සත්‍යාපනයක් නොමැත.

එමනිසා, පරිපූර්ණවාදියා නැවත හිස් කබලේ අඳුරු කෙළවරට හෝ ඔහු එහි වාඩි වී සිටින ඕනෑම තැනකට තල්ලු කරනු ලැබීය.

ඊට පස්සේ දවසක්, ලිපි කියවද්දී දේශීය ආධාරක උමං මාර්ග Linux වලදී මට FOU (Foo-over-UDP) හමු විය, i.e. කුමක් වුවත්, UDP වලින් ඔතා. මෙතෙක්, IPIP සහ GUE (Generic UDP Encapsulation) පමණක් සහය දක්වයි.

“මෙන්න රිදී උණ්ඩය! සරල IPIP එකක් මට ප්‍රමාණවත්.” - මම හිතුවා.

ඇත්ත වශයෙන්ම, උණ්ඩය සම්පූර්ණයෙන්ම රිදී නොවන බව පෙනී ගියේය. UDP හි ඇතුළත් කිරීම පළමු ගැටළුව විසඳයි - ඔබට පෙර ස්ථාපිත සම්බන්ධතාවයක් භාවිතයෙන් පිටත සිට NAT පිටුපස සිටින සේවාදායකයින් සමඟ සම්බන්ධ විය හැකිය, නමුත් මෙහිදී IPIP හි ඊළඟ අඩුපාඩුවෙන් අඩක් නව ආලෝකයකින් පිපෙන - පුද්ගලික ජාලයක ඕනෑම කෙනෙකුට දෘශ්‍යමාන පිටුපස සැඟවිය හැක. පොදු IP සහ සේවාදායක වරාය (පිරිසිදු IPIP හි මෙම ගැටළුව නොපවතී).

මෙම එකහමාරක ගැටළුව විසඳීම සඳහා, උපයෝගීතාව උපත ලැබීය ipipou. එය කර්නල් FOU හි ක්‍රියාකාරිත්වයට බාධා නොකර, දුරස්ථ ධාරකයක් සත්‍යාපනය කිරීම සඳහා ගෙදර හැදූ යාන්ත්‍රණයක් ක්‍රියාත්මක කරයි, එමඟින් කර්නල් අවකාශයේ පැකට් ඉක්මනින් හා කාර්යක්ෂමව ක්‍රියා කරයි.

අපට ඔබේ පිටපත අවශ්‍ය නැත!

හරි, ඔබ සේවාලාභියාගේ පොදු වරාය සහ IP දන්නේ නම් (උදාහරණයක් ලෙස, එය පිටුපස සිටින සියල්ලන්ම කොහේවත් යන්නේ නැත, NAT 1-in-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 - පොදු IP සේවාදායකය
• 198.51.100.2 - සේවාදායකයාගේ පොදු IP
• 192.168.0.2 — eth0 අතුරුමුහුණතට පවරා ඇති සේවාදායක IP
• 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

සත්‍යාපනය අවශ්‍ය නොවුවද, සේවාලාභියාගේ පොදු IP සහ තොට සැමවිටම නොදන්නා අතර ඒවා බොහෝ විට අනපේක්ෂිත හෝ විචල්‍ය වේ (NAT වර්ගය අනුව). ඔබ මග හැරියොත් encap-dport සේවාදායකය පැත්තෙන්, උමඟ ක්‍රියා නොකරනු ඇත, එය දුරස්ථ සම්බන්ධතා වරාය ගැනීමට තරම් බුද්ධිමත් නොවේ. මෙම අවස්ථාවේදී, ipipou හටද උදව් කළ හැකිය, නැතහොත් WireGuard සහ වෙනත් අය ඔබට උපකාර කළ හැකිය.

එය ක්රියාත්මක වන්නේ කෙසේද?

සේවාලාභියා (සාමාන්‍යයෙන් NAT ට පිටුපසින් සිටින) උමගක් විවෘත කරයි (ඉහත උදාහරණයේ මෙන්), සහ එහි පැත්තේ උමග වින්‍යාස කරන පරිදි සත්‍යාපන පැකට්ටුවක් සේවාදායකයට යවයි. සැකසීම් මත පදනම්ව, මෙය හිස් පැකට්ටුවක් විය හැකිය (සේවාදායකයට පොදු IP: සම්බන්ධතා වරාය දැකිය හැකි වන පරිදි), හෝ සේවාදායකයට සේවාදායකයා හඳුනාගත හැකි දත්ත සමඟ. දත්ත පැහැදිලි පාඨයක සරල මුර-වැකිකඩක් විය හැකිය (HTTP Basic Auth සමඟ සාදෘශ්‍යය මතකයට නැඟේ) හෝ පුද්ගලික යතුරකින් අත්සන් කර ඇති විශේෂයෙන් නිර්මාණය කරන ලද දත්ත (HTTP Digest Auth ට සමාන පමණක් ශක්තිමත්, ශ්‍රිතය බලන්න. client_auth කේතය තුළ).

සේවාදායකයේ (පොදු IP සහිත පැත්ත), ipipou ආරම්භ වූ විට, එය nfqueue පෝලිම් හසුරුවන්නක් නිර්මාණය කර netfilter වින්‍යාස කරන අතර එමඟින් අවශ්‍ය පැකට් තිබිය යුතු තැනට එවනු ලැබේ: පැකට් nfqueue පෝලිමට සම්බන්ධ කිරීම ආරම්භ කිරීම සහ [පාහේ] ඉතිරි සියල්ල අසන්නන් FOU වෙත කෙලින්ම යයි.

නොදන්නා අය සඳහා, nfqueue (හෝ NetfilterQueue) යනු කර්නල් මොඩියුල සංවර්ධනය කරන්නේ කෙසේදැයි නොදන්නා ආධුනිකයන් සඳහා විශේෂ දෙයක් වන අතර, netfilter (nftables/iptables) භාවිතයෙන් ඔබට ජාල පැකට් පරිශීලක අවකාශයට හරවා යැවීමට සහ ඒවා භාවිතා කර ඒවා සැකසීමට ඉඩ සලසයි. primitive යනු අත ළඟ: වෙනස් කරන්න (විකල්ප ) සහ එය නැවත කර්නලයට දෙන්න, නැතහොත් එය ඉවතලන්න.

සමහර ක්‍රමලේඛන භාෂා සඳහා nfqueue සමඟ වැඩ කිරීම සඳහා බන්ධන තිබේ, bash සඳහා කිසිවක් නොතිබුණි (heh, පුදුමයක් නොවේ), මට python භාවිතා කිරීමට සිදු විය: ipipou භාවිතා කරයි NetfilterQueue.

කාර්ය සාධනය තීරණාත්මක නොවේ නම්, මෙම දෙය භාවිතා කිරීමෙන් ඔබට තරමක් අඩු මට්ටමක පැකට් සමඟ වැඩ කිරීම සඳහා ඔබේම තර්කනය සාපේක්ෂ වශයෙන් ඉක්මනින් සහ පහසුවෙන් සකස් කළ හැකිය, උදාහරණයක් ලෙස, පර්යේෂණාත්මක දත්ත හුවමාරු ප්‍රොටෝකෝල සාදන්න, නැතහොත් සම්මත නොවන හැසිරීම් සහිත දේශීය සහ දුරස්ථ සේවාවන් ට්‍රොල් කරන්න.

අමු සොකට් nfqueue සමඟ අත්වැල් බැඳගෙන ක්‍රියා කරයි, උදාහරණයක් ලෙස, උමග දැනටමත් වින්‍යාස කර ඇති විට සහ FOU අපේක්ෂිත වරායට සවන් දෙන විට, ඔබට සුපුරුදු ආකාරයෙන් එම වරායෙන් පැකට්ටුවක් යැවීමට නොහැකි වනු ඇත - එය කාර්යබහුලයි, නමුත් ඔබට අමු සොකට් එකක් භාවිතයෙන් අහඹු ලෙස ජනනය කරන ලද පැකට්ටුවක් කෙලින්ම ජාල අතුරුමුහුණත වෙත ගෙන යැවිය හැක, නමුත් එවැනි පැකට්ටුවක් උත්පාදනය කිරීම සඳහා තව ටිකක් ටින්කර් කිරීම අවශ්‍ය වේ. ipipou හි සත්‍යාපනය සහිත පැකට් නිර්මාණය වන්නේ එලෙසය.

ipipou සකසන්නේ සම්බන්ධතාවයෙන් පළමු පැකට් පමණක් බැවින් (සහ සම්බන්ධතාවය ස්ථාපිත කිරීමට පෙර පෝලිමට කාන්දු වීමට සමත් වූ ඒවා), කාර්ය සාධනය පාහේ දුක් විඳින්නේ නැත.

ipipou සේවාදායකයට සත්‍යාපනය කළ පැකට්ටුවක් ලැබුණු විගස, උමගක් සාදනු ලබන අතර, සම්බන්ධතාවයේ ඇති සියලුම පසුකාලීන පැකට් දැනටමත් කර්නලය මගහැර nfqueue මඟින් සකසනු ලැබේ. සම්බන්ධතාවය අසමත් වුවහොත්, ඊළඟ පැකට්ටුවේ පළමු පැකට්ටුව nfqueue පෝලිමට යවනු ලැබේ, සැකසුම් මත පදනම්ව, එය සත්‍යාපනය සහිත පැකට්ටුවක් නොවේ නම්, නමුත් අවසාන වශයෙන් මතක තබා ගත් IP සහ සේවාදායක වරායෙන්, එය එක්කෝ සම්මත කළ හැකිය. මත හෝ ඉවතලන. සත්‍යාපිත පැකට්ටුවක් නව IP සහ වරායකින් පැමිණෙන්නේ නම්, ඒවා භාවිතා කිරීමට උමග නැවත සකස් කර ඇත.

NAT සමඟ වැඩ කරන විට සුපුරුදු IPIP-over-FOU හි තවත් එක් ගැටළුවක් ඇත - එකම IP සමඟ UDP තුළ කොටු කර ඇති IPIP උමං දෙකක් නිර්මාණය කළ නොහැක, මන්ද FOU සහ IPIP මොඩියුල එකිනෙකාගෙන් තරමක් හුදකලා වී ඇත. එම. එකම පොදු IP පිටුපස සිටින සේවාලාභීන් යුගලයකට මේ ආකාරයෙන් එකම සේවාදායකයට එකවර සම්බන්ධ වීමට නොහැකි වනු ඇත. අනාගතයේදී, විය හැකිය, එය කර්නල් මට්ටමින් විසඳනු ඇත, නමුත් මෙය නිශ්චිත නැත. මේ අතර, NAT ගැටළු NAT මගින් විසඳා ගත හැක - IP ලිපින යුගලයක් දැනටමත් වෙනත් උමගකින් අල්ලාගෙන තිබේ නම්, ipipou විසින් විකල්ප පුද්ගලික IP වෙත NAT කරනු ඇත, voila! - වරාය අවසන් වන තුරු ඔබට උමං සෑදිය හැක.

නිසා සම්බන්ධතාවයේ ඇති සියලුම පැකට් අත්සන් කර නැත, එවිට මෙම සරල ආරක්ෂණය MITM වෙත අවදානමට ලක් වේ, එබැවින් සේවාදායකයා සහ සේවාදායකයා අතර ගමනාගමනයට සවන් දී එය හැසිරවිය හැකි දුෂ්ටයෙකු සැඟවී සිටී නම්, ඔහුට සත්‍යාපනය කළ පැකට් නැවත යොමු කළ හැකිය. වෙනත් ලිපිනයක් සහ විශ්වාස නොකළ ධාරකයෙකුගෙන් උමගක් සාදන්න.

හරය තුළ ඇති තදබදයෙන් වැඩි ප්‍රමාණයක් ඉතිරි කරන අතරතුර මෙය නිවැරදි කරන්නේ කෙසේද යන්න පිළිබඳව යමෙකුට අදහස් තිබේ නම්, කතා කිරීමට පසුබට නොවන්න.

මාර්ගය වන විට, UDP හි ආවරණය කිරීම ඉතා හොඳින් ඔප්පු වී ඇත. IP හරහා සංග්‍රහ කිරීම හා සසඳන විට, UDP ශීර්ෂයේ අතිරේක පොදු කාර්ය තිබියදී එය වඩා ස්ථායී සහ බොහෝ විට වේගවත් වේ. මෙයට හේතුව අන්තර්ජාලයේ බොහෝ සත්කාරකයන් හොඳින් ක්‍රියා කරන්නේ වඩාත් ජනප්‍රිය ප්‍රොටෝකෝල තුන සමඟ පමණි: TCP, UDP, ICMP. ප්‍රත්‍යක්ෂ කොටසට අනෙක් සියල්ල සම්පූර්ණයෙන්ම ඉවත දැමිය හැකිය, නැතහොත් එය වඩාත් සෙමින් ක්‍රියාවට නැංවිය හැකිය, මන්ද එය මෙම තුන සඳහා පමණක් ප්‍රශස්ත කර ඇත.

උදාහරණයක් ලෙස, HTTP/3 මත පදනම් වූ QUICK නිර්මාණය කර ඇත්තේ UDP මත මිස IP මත නොවේ.

හොඳයි, ප්රමාණවත් තරම් වචන, එය "සැබෑ ලෝකයේ" ක්රියා කරන ආකාරය බැලීමට කාලයයි.

සටන

සැබෑ ලෝකය අනුකරණය කිරීමට භාවිතා කරයි iperf3. යථාර්ථයට සමීප වීමේ මට්ටම අනුව, මෙය Minecraft හි සැබෑ ලෝකය අනුකරණය කිරීමට ආසන්න වශයෙන් සමාන වේ, නමුත් දැනට එය කරනු ඇත.

තරඟයට සහභාගිවන්නන්:

• යොමු ප්රධාන නාලිකාව
• මෙම ලිපියේ වීරයා ipipou ය
• සත්‍යාපනය සහිත OpenVPN නමුත් සංකේතාංකනය නොමැත
• OpenVPN සියල්ල ඇතුළත් මාදිලියේ
• PresharedKey නොමැතිව WireGuard, 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

ප්රතිඵල

තෙත් කැත ලකුණ
සේවාදායකයේ CPU පැටවීම එතරම් ඇඟවුම් නොකරයි, මන්ද... තවත් බොහෝ සේවාවන් එහි ක්‍රියාත්මක වේ, සමහර විට ඒවා සම්පත් අනුභව කරයි:

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 නාලිකාව

ශුභවාදී Gbps 1කට නාලිකාව

සෑම අවස්ථාවකදීම, ipipou මූලික නාලිකාවට කාර්ය සාධනය තරමක් සමීප වේ, එය විශිෂ්ටයි!

සංකේතනය නොකළ openvpn උමඟ අවස්ථා දෙකේදීම තරමක් අමුතු ලෙස හැසිරුණි.

යමෙකු එය පරීක්ෂා කිරීමට යන්නේ නම්, ප්‍රතිපෝෂණ ඇසීම සිත්ගන්නාසුළු වනු ඇත.

IPv6 සහ NetPrickle අප සමඟ වේවා!

මූලාශ්රය: www.habr.com