🥇ipipou: صرف هڪ غير انڪرپٽ ٿيل سرنگ کان وڌيڪ

اسان IPv6 ديوتا کي ڇا چئون؟

سچ، ۽ اسين اڄ انڪرپشن جي ديوتا کي به اهو ئي چونداسين.

هي هڪ غير انڪرپٽ ٿيل IPv4 سرنگ بابت آهي، "گرم ٽيوب" واري نه، پر هڪ جديد "LED" واري. خام ساکٽ پڻ موجود آهن، ۽ پيڪٽ پروسيسنگ صارف جي جڳهه ۾ ٿيندي آهي.

هر ذائقي ۽ رنگ جي مناسبت سان اين ٽنلنگ پروٽوڪول موجود آهن:

سجيل، فيشنيبل، نوجوان وائر ڪارڊ
ملٽي فنڪشنل، جهڙوڪ سوئس چاقو، اوپن وي پي اين ۽ ايس ايس ايڇ
پراڻو ۽ خراب نه GRE
سڀ کان سادو، تيز، ۽ مڪمل طور تي غير انڪرپٽ ٿيل IPIP
فعال طور تي ترقي ڪندڙ جنيوا
ٻيا ڪيترائي.

پر مان هڪ پروگرامر آهيان، تنهن ڪري مان صرف N کي هڪ حصي سان وڌائيندس، ۽ مان حقيقي پروٽوڪول جي ترقي کي ڪامرسنٽ ڊولپرز تي ڇڏي ڏيندس.

هڪ ۾ جيڪو اڃا پيدا نه ٿيو آهي منصوبوجنهن منصوبي تي مان هن وقت ڪم ڪري رهيو آهيان، ان لاءِ ٻاهر کان NAT جي پويان هوسٽ تائين رسائي جي ضرورت آهي. جديد ڪرپٽوگرافي سان پروٽوڪول استعمال ڪندي، مان اهو احساس ختم نه ڪري سگهيس ته اهو هڪ چڙيا کي توپ سان مارڻ وانگر هو. جيئن ته سرنگ گهڻو ڪري صرف NAT ۾ سوراخ ڪرڻ لاءِ استعمال ڪئي ويندي آهي، اندروني ٽرئفڪ عام طور تي انڪرپٽ ڪئي ويندي آهي - HTTPS اڃا تائين ترجيحي طريقو آهي.

مختلف سرنگنگ پروٽوڪول تي تحقيق ڪندي، منهنجو اندروني ڪمال پسند بار بار IPIP ڏانهن متوجه ٿيو ڇاڪاڻ ته ان جي گهٽ ۾ گهٽ اوور هيڊ هئي. پر ان ۾ منهنجي ضرورتن لاءِ هڪ ۽ اڌ اهم خاميون آهن:

ان کي ٻنهي پاسن کان عوامي IP جي ضرورت آهي،
۽ توهان لاءِ ڪا به تصديق ناهي.

تنهنڪري ڪمال پسند کي سندس کوپڙي جي اونداهي ڪنڊ ۾، يا جتي به هو ويٺو هو، واپس ڌڪيو ويو.

۽ پوءِ هڪ ڏينهن، مضمون پڙهڻ دوران مقامي طور تي سپورٽ ٿيل سرنگون لينڪس ۾، مون کي FOU (Foo-over-UDP) مليو، يعني، UDP ۾ لپيٽيل ڪا به شيءِ ۽ هر شيءِ. هن وقت، صرف سپورٽ ٿيل "ڪنهن به شيءِ ۽ هر شيءِ" IPIP ۽ GUE (Generic UDP Encapsulation) آهن.

"هي آهي، چانديءَ جي گولي! هڪ سادو IPIP منهنجي لاءِ ڪافي کان وڌيڪ آهي،" مون سوچيو.

حقيقت ۾، گولي مڪمل طور تي چانديءَ جي پرت نه هئي. UDP انڪيپسوليشن پهرين مسئلي کي حل ڪري ٿو - NAT جي پويان ڪلائنٽ کي اڳ ۾ قائم ٿيل ڪنيڪشن استعمال ڪندي ٻاهر کان ڳنڍي سگهجي ٿو - پر هي IPIP جي خامين جي ٻئي اڌ کي نمايان ڪري ٿو: خانگي نيٽ ورڪ تي ڪو به ماڻهو ڪلائنٽ جي نظر ايندڙ عوامي IP پتي ۽ پورٽ جي پويان لڪائي سگهي ٿو (هي مسئلو خالص IPIP ۾ موجود ناهي).

هن ڏيڍ مسئلي کي حل ڪرڻ لاءِ، افاديت پيدا ٿي. ايپيپواهو ڪرنل تي ٻڌل FOU کي خراب ڪرڻ کان سواءِ گهر ۾ ٺهيل ريموٽ هوسٽ تصديق جو طريقو لاڳو ڪري ٿو، جيڪو ڪرنل اسپيس ۾ پيڪٽس کي جلدي ۽ ڪارآمد طريقي سان پروسيس ڪندو.

مون کي توهان جي اسڪرپٽ جي ضرورت ناهي!

ٺيڪ آهي، جيڪڏهن توهان ڪلائنٽ جي پبلڪ پورٽ ۽ IP کي ڄاڻو ٿا (مثال طور، ان جي پويان هرڪو ڪٿي به نه ٿو وڃي، NAT پورٽس 1-to-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 — ڪلائنٽ IP انٽرفيس 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

جيتوڻيڪ تصديق جي ضرورت نه آهي، ڪلائنٽ جو عوامي IP ۽ پورٽ هميشه سڃاتل نه هوندا آهن ۽ اڪثر ڪري غير متوقع يا متغير هوندا آهن (NAT قسم تي منحصر ڪري). جيڪڏهن توهان ڇڏي ڏيو ٿا encap-dport سرور واري پاسي، سرنگ ڪم نه ڪندي؛ اهو ريموٽ ڪنيڪشن پورٽ استعمال ڪرڻ لاءِ ڪافي هوشيار ناهي. هن صورت ۾، ipipou پڻ مدد ڪري سگهي ٿو، جيئن وائر گارڊ ۽ ان وانگر.

ان کي ڪيئن ڪم ڪندو؟

ڪلائنٽ (عام طور تي NAT جي پويان) هڪ سرنگ قائم ڪري ٿو (جيئن مٿي ڏنل مثال ۾) ۽ سرور ڏانهن هڪ تصديق پيڪٽ موڪلي ٿو ته جيئن اهو سرنگ کي ان جي آخر ۾ سيٽ ڪري سگهي. سيٽنگن تي منحصر ڪري، هي هڪ خالي پيڪٽ ٿي سگهي ٿو (صرف انهي ڪري ته سرور ڪنيڪشن جو عوامي IP ۽ پورٽ ڏسي سگهي)، يا ان ۾ ڊيٽا شامل ٿي سگهي ٿو جيڪو سرور ڪلائنٽ کي سڃاڻڻ لاءِ استعمال ڪري سگهي ٿو. هي ڊيٽا هڪ سادي صاف ٽيڪسٽ پاس فريز ٿي سگهي ٿو (HTTP بنيادي تصديق سان هڪ تشبيه ذهن ۾ اچي ٿي) يا خاص طور تي فارميٽ ٿيل ڊيٽا هڪ خانگي ڪي سان سائن ڪيو ويو آهي (HTTP ڊائجسٽ تصديق سان ملندڙ جلندڙ، صرف مضبوط؛ فنڪشن ڏسو client_auth ڪوڊ ۾).

سرور تي (عوامي IP واري پاسي)، جڏهن ipipou شروع ٿئي ٿو، اهو هڪ nfqueue قطار هينڊلر ٺاهي ٿو ۽ نيٽ فلٽر کي ترتيب ڏئي ٿو ته جيئن گهربل پيڪيٽس کي هدايت ڪئي وڃي جتي انهن کي هجڻ گهرجي: ڪنيڪشن شروع ڪندڙ پيڪيٽس nfqueue قطار ڏانهن ويندا آهن، ۽ [تقريبن] باقي سڀ ڪجهه سڌو سنئون FOU ٻڌندڙ ڏانهن ويندو آهي.

انهن لاءِ جيڪي نٿا ڄاڻن، nfqueue (يا NetfilterQueue) شوقينن لاءِ هڪ خاص شيءِ آهي جيڪي نٿا ڄاڻن ته ڪرنل ماڊل ڪيئن ٺاهجن. اهو نيٽ فلٽر (nftables/iptables) استعمال ڪري ٿو نيٽ ورڪ پيڪٽس کي يوزر اسپيس ڏانهن ريڊائريڪٽ ڪرڻ ۽ انهن کي اتي پروسيس ڪرڻ لاءِ پرائميٽو ٽولز استعمال ڪندي هٿ ۾: انهن کي تبديل ڪريو (اختياري طور تي) ۽ انهن کي واپس ڪرنل ڏانهن منتقل ڪريو، يا انهن کي رد ڪريو.

ڪجھ پروگرامنگ ٻولين لاءِ nfqueue سان ڪم ڪرڻ لاءِ بائنڊنگز آهن، bash لاءِ ڪو به نه هو (هي، حيرت انگيز نه آهي)، مون کي پٿون استعمال ڪرڻو پيو: ipipou استعمال ڪري ٿو نيٽ فلٽر قطار.

جيڪڏهن ڪارڪردگي نازڪ نه آهي، ته پوءِ هي شيءِ نسبتاً تيز ۽ آساني سان توهان جي پنهنجي گهٽ-سطح جي پيڪٽ هينڊلنگ منطق کي تيز ڪرڻ لاءِ استعمال ڪري سگهجي ٿي، جهڙوڪ تجرباتي ڊيٽا ٽرانسفر پروٽوڪول ٺاهڻ يا غير معياري رويي سان مقامي ۽ ريموٽ سروسز کي ٽرول ڪرڻ.

خام ساکٽ nfqueue سان هٿ ۾ هٿ ملائي ڪم ڪن ٿا. مثال طور، جڏهن هڪ سرنگ اڳ ۾ ئي ترتيب ڏنل آهي ۽ FOU گهربل پورٽ تي ٻڌي رهيو آهي، ته ان پورٽ مان معمول جي طريقي سان هڪ پيڪٽ موڪلڻ ممڪن ناهي - اهو مصروف آهي. جڏهن ته، توهان خام ساکٽ استعمال ڪندي نيٽ ورڪ انٽرفيس تي بي ترتيب طور تي ٺاهيل پيڪٽ کي فائر ڪري سگهو ٿا، جيتوڻيڪ اهڙي پيڪٽ کي ٺاهڻ لاءِ ٿوري وڌيڪ ڪوشش جي ضرورت آهي. اهڙي طرح ipipou ۾ تصديق جا پيڪٽ ٺاهيا ويندا آهن.

جيئن ته ipipou ڪنيڪشن مان صرف پهرين پيڪٽس کي پروسيس ڪري ٿو (۽ اهي جيڪي ڪنيڪشن قائم ٿيڻ کان اڳ قطار ۾ لڪي ويا هئا)، ڪارڪردگي تقريبن متاثر نه ٿيندي آهي.

جيئن ئي ipipou سرور هڪ تصديق ٿيل پيڪٽ حاصل ڪري ٿو، هڪ سرنگ ٺاهي ويندي آهي، ۽ ڪنيڪشن ۾ ايندڙ سڀئي پيڪٽ nfqueue کي نظرانداز ڪندي، ڪرنل ذريعي پروسيس ڪيا ويندا آهن. جيڪڏهن ڪنيڪشن ختم ٿي ويندو آهي، ته ايندڙ ڪنيڪشن جو پهريون پيڪٽ nfqueue قطار ڏانهن موڪليو ويندو. سيٽنگن تي منحصر ڪري، جيڪڏهن اهو هڪ تصديق ٿيل پيڪٽ نه آهي، پر ڪلائنٽ جي آخري ياد ڪيل IP ۽ پورٽ مان، اهو يا ته منتقل ٿي سگهي ٿو يا رد ڪري سگهجي ٿو. جيڪڏهن هڪ تصديق ٿيل پيڪٽ هڪ نئين IP ۽ پورٽ مان اچي ٿو، ته سرنگ انهن کي استعمال ڪرڻ لاءِ ٻيهر ترتيب ڏني ويندي آهي.

معياري IPIP-over-FOU ۾ NAT سان ڪم ڪرڻ وقت هڪ ٻيو مسئلو آهي: ساڳئي IP پتي سان ٻه UDP-encapsulated IPIP سرنگون ٺاهڻ ناممڪن آهي، ڇاڪاڻ ته FOU ۽ IPIP ماڊل هڪ ٻئي کان ڪافي الڳ ٿيل آهن. ان جو مطلب آهي ته ساڳئي عوامي IP پتي جي پويان ٻه ڪلائنٽ هڪ ئي وقت ساڳئي سرور سان هن طريقي سان ڳنڍڻ جي قابل نه هوندا. مستقبل ۾، ممڪن آهياهو ڪرنل جي سطح تي حل ٿي ويندو، پر اهو يقيني ناهي. انهي دوران، NAT مسئلا NAT سان حل ٿي سگهن ٿا - جيڪڏهن IP پتي جو هڪ جوڙو اڳ ۾ ئي ڪنهن ٻئي سرنگ تي قبضو ڪري چڪو آهي، ته ipipou عوامي IP کي هڪ متبادل خانگي IP ڏانهن NAT ڪندو، ۽ وائيلا! توهان سرنگون ٺاهي سگهو ٿا جيستائين توهان جي پورٽ ختم نه ٿي وڃن.

جيئن ته ڪنيڪشن ۾ سڀئي پيڪٽ سائن ٿيل نه آهن، هي سادو تحفظ MITM حملن لاءِ خطرناڪ آهي. جيڪڏهن ڪلائنٽ ۽ سرور جي وچ ۾ ڪو خراب اداڪار لڪيل آهي جيڪو ٽرئفڪ کي ٻڌي ۽ ان کي هٿي ڏئي سگهي ٿو، ته اهي تصديق ٿيل پيڪٽ کي هڪ مختلف ايڊريس ذريعي ريڊائريڪٽ ڪري سگهن ٿا ۽ هڪ غير قابل اعتماد هوسٽ کان هڪ سرنگ ٺاهي سگهن ٿا.

جيڪڏهن ڪنهن وٽ ڪو خيال آهي ته ٽرئفڪ جي وڏي حصي کي بنيادي طور تي رکندي هن کي ڪيئن درست ڪجي، مهرباني ڪري ڳالهائڻ لاءِ آزاد محسوس ڪريو.

اتفاق سان، UDP انڪيپسوليشن پاڻ کي تمام گهڻو اثرائتو ثابت ڪيو آهي. IP انڪيپسوليشن جي مقابلي ۾، اهو گهڻو وڌيڪ مستحڪم ۽ اڪثر تيز آهي، UDP هيڊر جي اضافي اوور هيڊ جي باوجود. اهو ئي سبب آهي جو انٽرنيٽ تي گهڻا هوسٽ صرف ٽن مشهور پروٽوڪول سان سٺو ڪم ڪن ٿا: TCP، UDP، ۽ ICMP. هڪ اهم تعداد ٻين سڀني پروٽوڪول کي مڪمل طور تي رد ڪري سگهي ٿو، يا انهن کي وڌيڪ سست رفتاري سان پروسيس ڪري سگهي ٿو، ڇاڪاڻ ته اهي صرف انهن ٽنهي لاءِ بهتر ڪيا ويا آهن.

مثال طور، اهو ئي سبب آهي جو QUICK، جنهن تي HTTP/3 ٻڌل آهي، UDP جي مٿان ٺاهيو ويو، IP جي مٿان نه.

خير، ڪافي لفظ، اهو ڏسڻ جو وقت آهي ته اهو "حقيقي دنيا" ۾ ڪيئن ڪم ڪري ٿو.

جنگ

حقيقي دنيا جي نقل ڪرڻ لاءِ ان کي استعمال ڪيو ويندو آهي iperf3حقيقت جي ويجهو هجڻ جي لحاظ کان، اهو Minecraft جي حقيقي دنيا جي ايموليشن وانگر ئي آهي، پر اهو هاڻي لاءِ ڪم ڪندو.

مقابلي ۾ هيٺيان شرڪت ڪندڙ حصو وٺندا:

حوالو مکيه چينل
هن مضمون جو هيرو ايپيپو آهي.
اوپن وي پي اين تصديق سان پر ڪابه انڪرپشن ناهي
اوپن وي پي اين آل انڪلوسيو موڊ ۾
وائر گارڊ بغير پري شيئرڊ ڪي جي، MTU=1440 سان (ڇاڪاڻ ته صرف IPv4 لاءِ)

گيڪس لاءِ ٽيڪنيڪل ڊيٽا
ميٽرڪ اهڙن حڪمن ذريعي ورتا ويندا آهن.

گراهڪ تي:

يو ايس پي

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", чтобы лишние пакеты не плодить и не портить производительность.

ٽي پي

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

سرور تي (ڪلائنٽ سان گڏ هلندو آهي):

يو ايس پي

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

ٽي پي

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

سرنگ جي ترتيب

ايپيپو
سرور
/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 --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

اوپن وي پي اين (انڪرپشن، تصديق سان، يو ڊي پي ذريعي، سڀ ڪجهه جيئن هجڻ گهرجي)
استعمال ڪندي ترتيب ڏنل اوپن وي پي اين-مينيج

وائر گارڊ
سرور
/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 ايم بي پي ايس چينل

1 مثبت Gbps تي چينل