ipipou: শুধুমাত্র একটি এনক্রিপ্ট করা টানেলের চেয়েও বেশি কিছু

আমরা IPv6 এর ঈশ্বরকে কি বলছি?

এটা ঠিক, আমরা আজ এনক্রিপশনের দেবতাকেও একই কথা বলব।

এখানে আমরা একটি এনক্রিপ্ট করা IPv4 টানেল সম্পর্কে কথা বলব, তবে একটি "উষ্ণ বাতি" সম্পর্কে নয়, একটি আধুনিক "LED" সম্পর্কে কথা বলব৷ এবং এখানে কাঁচা সকেটগুলিও ফ্ল্যাশ করছে, এবং ব্যবহারকারীর জায়গায় প্যাকেটগুলি নিয়ে কাজ চলছে।

প্রতিটি স্বাদ এবং রঙের জন্য এন টানেলিং প্রোটোকল রয়েছে:

• আড়ম্বরপূর্ণ, ফ্যাশনেবল, যুবক WireGuard
• বহুমুখী, যেমন সুইস ছুরি, ওপেনভিপিএন এবং এসএসএইচ
• পুরানো এবং খারাপ জিআরই নয়
• সবচেয়ে সহজ, দ্রুত, সম্পূর্ণরূপে আনক্রিপ্ট করা IPIP
• সক্রিয়ভাবে উন্নয়নশীল জেনেভ
• অনেকে.

কিন্তু আমি একজন প্রোগ্রামার, তাই আমি শুধুমাত্র একটি ভগ্নাংশ দ্বারা N বৃদ্ধি করব এবং প্রকৃত প্রোটোকলের বিকাশ কমার্স্যান্ট ডেভেলপারদের কাছে ছেড়ে দেব।

এক অনাগতে প্রকল্পআমি এখন যা করছি তা হল বাইরে থেকে NAT এর পিছনে হোস্টদের কাছে পৌঁছানো। এটির জন্য প্রাপ্তবয়স্কদের ক্রিপ্টোগ্রাফি সহ প্রোটোকল ব্যবহার করে, আমি এই অনুভূতিটি নাড়াতে পারিনি যে এটি একটি কামান থেকে চড়ুইকে গুলি করার মতো। কারণ টানেলটি বেশিরভাগ অংশে শুধুমাত্র NAT-e-তে ছিদ্র করার জন্য ব্যবহৃত হয়, অভ্যন্তরীণ ট্র্যাফিক সাধারণত এনক্রিপ্ট করা হয়, কিন্তু তারা এখনও HTTPS-এ ডুবে যায়।

বিভিন্ন টানেলিং প্রোটোকল নিয়ে গবেষণা করার সময়, ন্যূনতম ওভারহেডের কারণে আমার অভ্যন্তরীণ পারফেকশনিস্টের মনোযোগ বারবার আইপিআইপি-র প্রতি আকৃষ্ট হয়েছিল। কিন্তু আমার কাজের জন্য এটির দেড় উল্লেখযোগ্য ত্রুটি রয়েছে:

• এটি উভয় দিকে পাবলিক আইপি প্রয়োজন,
• এবং আপনার জন্য কোন প্রমাণীকরণ নেই।

অতএব, পরিপূর্ণতাবাদীকে মাথার খুলির অন্ধকার কোণে বা যেখানেই তিনি সেখানে বসেন সেখানে ফিরে চালিত হয়েছিল।

এবং তারপর একদিন, নিবন্ধ পড়ার সময় স্থানীয়ভাবে সমর্থিত টানেল লিনাক্সে আমি FOU (Foo-over-UDP) জুড়ে এসেছি, অর্থাৎ যাই হোক না কেন, UDP-তে মোড়ানো। এখন পর্যন্ত, শুধুমাত্র IPIP এবং GUE (জেনারিক UDP এনক্যাপসুলেশন) সমর্থিত।

“এই যে সিলভার বুলেট! একটি সাধারণ আইপিআইপি আমার জন্য যথেষ্ট।" - আমি ভাবি.

আসলে, বুলেটটি পুরোপুরি রূপালী নয়। UDP-তে এনক্যাপসুলেশন প্রথম সমস্যার সমাধান করে - আপনি পূর্ব-স্থাপিত সংযোগ ব্যবহার করে বাইরে থেকে NAT-এর পিছনে থাকা ক্লায়েন্টদের সাথে সংযোগ করতে পারেন, কিন্তু এখানে IPIP-এর পরবর্তী ত্রুটির অর্ধেকটি নতুন আলোয় ফুটে উঠেছে - একটি ব্যক্তিগত নেটওয়ার্ক থেকে যে কেউ দৃশ্যমানের পিছনে লুকিয়ে থাকতে পারে পাবলিক আইপি এবং ক্লায়েন্ট পোর্ট (বিশুদ্ধ আইপিআইপিতে এই সমস্যাটি বিদ্যমান নেই)।

এই দেড় সমস্যা সমাধানের জন্যই জন্ম নেয় ইউটিলিটি ipipou. এটি কার্নেল FOU-এর ক্রিয়াকলাপকে ব্যাহত না করে একটি দূরবর্তী হোস্টকে প্রমাণীকরণের জন্য একটি বাড়িতে তৈরি প্রক্রিয়া প্রয়োগ করে, যা কার্নেল স্পেসে প্যাকেটগুলি দ্রুত এবং দক্ষতার সাথে প্রক্রিয়া করবে।

আমরা আপনার স্ক্রিপ্ট প্রয়োজন নেই!

ঠিক আছে, আপনি যদি ক্লায়েন্টের পাবলিক পোর্ট এবং আইপি জানেন (উদাহরণস্বরূপ, এর পিছনের সবাই কোথাও যায় না, NAT পোর্ট 1-in-1 ম্যাপ করার চেষ্টা করে), আপনি একটি IPIP-ওভার-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 — ক্লায়েন্ট টানেল ইন্টারফেসের আইপি (ব্যক্তিগত)
• 172.28.0.0 — আইপি টানেল সার্ভার ইন্টারফেস (ব্যক্তিগত)

যতক্ষণ UDP সংযোগটি জীবিত থাকে, টানেলটি কার্যকরী ক্রমে থাকবে, কিন্তু যদি এটি ভেঙে যায়, আপনি ভাগ্যবান হবেন - যদি ক্লায়েন্টের আইপি: পোর্ট একই থাকে - এটি বেঁচে থাকবে, যদি তারা পরিবর্তন হয় - এটি ভেঙে যাবে।

সবকিছু ফিরিয়ে আনার সবচেয়ে সহজ উপায় হল কার্নেল মডিউলগুলি আনলোড করা: modprobe -r fou ipip

প্রমাণীকরণের প্রয়োজন না হলেও, ক্লায়েন্টের সর্বজনীন আইপি এবং পোর্ট সবসময় পরিচিত হয় না এবং প্রায়শই অপ্রত্যাশিত বা পরিবর্তনশীল (NAT প্রকারের উপর নির্ভর করে)। বাদ দিলে encap-dport সার্ভারের দিকে, টানেল কাজ করবে না, এটি দূরবর্তী সংযোগ পোর্ট নিতে যথেষ্ট স্মার্ট নয়। এই ক্ষেত্রে, ipipouও সাহায্য করতে পারে, অথবা WireGuard এবং এর মতো অন্যরা আপনাকে সাহায্য করতে পারে।

এটা কিভাবে কাজ করে?

ক্লায়েন্ট (যা সাধারণত NAT এর পিছনে থাকে) একটি টানেল খোলে (উপরের উদাহরণের মতো), এবং সার্ভারে একটি প্রমাণীকরণ প্যাকেট পাঠায় যাতে এটি তার পাশের টানেলটি কনফিগার করে। সেটিংসের উপর নির্ভর করে, এটি একটি খালি প্যাকেট হতে পারে (যেন সার্ভারটি সর্বজনীন আইপি দেখতে পারে: সংযোগ পোর্ট), অথবা এমন ডেটা যা দ্বারা সার্ভার ক্লায়েন্টকে সনাক্ত করতে পারে। ডেটা স্পষ্ট পাঠ্যে একটি সাধারণ পাসফ্রেজ হতে পারে (এইচটিটিপি বেসিক প্রমাণের সাথে সাদৃশ্যটি মনে আসে) বা একটি ব্যক্তিগত কী দিয়ে স্বাক্ষরিত বিশেষভাবে ডিজাইন করা ডেটা হতে পারে (এইচটিটিপি ডাইজেস্ট প্রমাণের মতোই শক্তিশালী, ফাংশন দেখুন client_auth কোডে)।

সার্ভারে (পাবলিক আইপি সহ), যখন ipipou শুরু হয়, এটি একটি nfqueue সারি হ্যান্ডলার তৈরি করে এবং নেটফিল্টার কনফিগার করে যাতে প্রয়োজনীয় প্যাকেটগুলি যেখানে পাঠানো উচিত সেখানে পাঠানো হয়: প্যাকেটগুলি nfqueue সারিতে সংযোগ শুরু করে এবং [প্রায়] বাকি সব শ্রোতা FOU সরাসরি যান.

যারা জানেন না তাদের জন্য, nfqueue (বা NetfilterQueue) অপেশাদারদের জন্য একটি বিশেষ জিনিস যারা কার্নেল মডিউলগুলি কীভাবে বিকাশ করতে হয় তা জানেন না, যা নেটফিল্টার (nftables/iptables) ব্যবহার করে আপনাকে নেটওয়ার্ক প্যাকেটগুলিকে ব্যবহারকারীর স্থানে পুনঃনির্দেশ করতে দেয় এবং সেগুলি ব্যবহার করে সেখানে প্রক্রিয়া করতে দেয়। আদিম অর্থ হাতের কাছে: সংশোধন করুন (ঐচ্ছিক) এবং এটি কার্নেলে ফিরিয়ে দিন, বা বাতিল করুন।

কিছু প্রোগ্রামিং ভাষার জন্য nfqueue এর সাথে কাজ করার জন্য বাইন্ডিং রয়েছে, ব্যাশের জন্য সেখানে কিছুই ছিল না (হে, আশ্চর্যজনক নয়), আমাকে পাইথন ব্যবহার করতে হয়েছিল: ipipou ব্যবহার করে নেটফিল্টার সারি.

কর্মক্ষমতা সমালোচনামূলক না হলে, এই জিনিসটি ব্যবহার করে আপনি মোটামুটি নিম্ন স্তরে প্যাকেটগুলির সাথে কাজ করার জন্য তুলনামূলকভাবে দ্রুত এবং সহজেই আপনার নিজস্ব যুক্তি তৈরি করতে পারেন, উদাহরণস্বরূপ, পরীক্ষামূলক ডেটা স্থানান্তর প্রোটোকল তৈরি করুন, বা অ-মানক আচরণের সাথে স্থানীয় এবং দূরবর্তী পরিষেবাগুলিকে ট্রল করুন৷

কাঁচা সকেটগুলি nfqueue-এর সাথে হাতে হাত মিলিয়ে কাজ করে, উদাহরণস্বরূপ, যখন টানেলটি ইতিমধ্যেই কনফিগার করা থাকে এবং FOU কাঙ্ক্ষিত পোর্টে শুনছে, তখন আপনি একই পোর্ট থেকে স্বাভাবিক উপায়ে একটি প্যাকেট পাঠাতে পারবেন না - এটি ব্যস্ত, কিন্তু আপনি একটি কাঁচা সকেট ব্যবহার করে সরাসরি নেটওয়ার্ক ইন্টারফেসে একটি এলোমেলোভাবে জেনারেট করা প্যাকেট নিতে এবং পাঠাতে পারেন, যদিও এই ধরনের একটি প্যাকেট তৈরি করতে একটু বেশি টিঙ্কারিং প্রয়োজন হবে। এভাবেই ipipou-এ প্রমাণীকরণ সহ প্যাকেট তৈরি করা হয়।

যেহেতু ipipou সংযোগ থেকে শুধুমাত্র প্রথম প্যাকেটগুলিকে প্রক্রিয়া করে (এবং যেগুলি সংযোগ স্থাপনের আগে সারিতে ফুটো হয়ে গিয়েছিল), কার্যক্ষমতা প্রায় ক্ষতিগ্রস্ত হয় না।

যত তাড়াতাড়ি ipipou সার্ভার একটি প্রমাণীকৃত প্যাকেট পায়, একটি টানেল তৈরি করা হয় এবং সংযোগের সমস্ত পরবর্তী প্যাকেট ইতিমধ্যেই nfqueue বাইপাস করে কার্নেল দ্বারা প্রক্রিয়া করা হয়। যদি সংযোগটি ব্যর্থ হয়, তবে পরবর্তীটির প্রথম প্যাকেটটি সেটিংসের উপর নির্ভর করে nfqueue সারিতে পাঠানো হবে, যদি এটি প্রমাণীকরণ সহ একটি প্যাকেট না হয়, তবে শেষ মনে রাখা আইপি এবং ক্লায়েন্ট পোর্ট থেকে এটি পাস করা যেতে পারে। চালু বা বাতিল যদি একটি প্রমাণীকৃত প্যাকেট একটি নতুন আইপি এবং পোর্ট থেকে আসে, তাহলে তাদের ব্যবহার করার জন্য টানেলটি পুনরায় কনফিগার করা হয়।

NAT-এর সাথে কাজ করার সময় স্বাভাবিক IPIP-ওভার-FOU-এর আরও একটি সমস্যা রয়েছে - একই IP দিয়ে UDP-তে দুটি IPIP টানেল তৈরি করা অসম্ভব, কারণ FOU এবং IPIP মডিউলগুলি একে অপরের থেকে বেশ বিচ্ছিন্ন। সেগুলো. একই পাবলিক আইপির পিছনে একজোড়া ক্লায়েন্ট একই সাথে একই সার্ভারের সাথে এইভাবে সংযোগ করতে সক্ষম হবে না। ভবিষ্যতে, সম্ভবত, এটি কার্নেল স্তরে সমাধান করা হবে, কিন্তু এটি নিশ্চিত নয়। ইতিমধ্যে, NAT সমস্যাগুলি NAT দ্বারা সমাধান করা যেতে পারে - যদি এমন হয় যে এক জোড়া IP ঠিকানা ইতিমধ্যেই অন্য একটি টানেল দ্বারা দখল করা হয়েছে, ipipou জনসাধারণের থেকে একটি বিকল্প ব্যক্তিগত আইপিতে NAT করবে, voila! - পোর্টগুলি শেষ না হওয়া পর্যন্ত আপনি টানেল তৈরি করতে পারেন।

কারণ সংযোগের সমস্ত প্যাকেট সাইন করা হয় না, তাহলে এই সাধারণ সুরক্ষা এমআইটিএম-এর জন্য ঝুঁকিপূর্ণ, তাই যদি ক্লায়েন্ট এবং সার্ভারের মধ্যে কোনও ভিলেন লুকিয়ে থাকে যে ট্র্যাফিক শুনতে এবং এটিকে ম্যানিপুলেট করতে পারে, তবে সে এর মাধ্যমে প্রমাণীকৃত প্যাকেটগুলিকে পুনঃনির্দেশ করতে পারে অন্য ঠিকানা এবং একটি অবিশ্বস্ত হোস্ট থেকে একটি টানেল তৈরি করুন।

ট্রাফিকের মূল অংশ ছেড়ে যাওয়ার সময় কীভাবে এটি ঠিক করা যায় সে সম্পর্কে কারও কাছে ধারণা থাকলে, কথা বলতে দ্বিধা করবেন না।

যাইহোক, ইউডিপিতে এনক্যাপসুলেশন নিজেকে খুব ভালভাবে প্রমাণ করেছে। আইপির উপর এনক্যাপসুলেশনের তুলনায়, এটি UDP হেডারের অতিরিক্ত ওভারহেড সত্ত্বেও অনেক বেশি স্থিতিশীল এবং প্রায়শই দ্রুত। এটি এই কারণে যে ইন্টারনেটে বেশিরভাগ হোস্ট শুধুমাত্র তিনটি জনপ্রিয় প্রোটোকলের সাথে ভাল কাজ করে: TCP, UDP, ICMP। বাস্তব অংশটি সম্পূর্ণরূপে অন্য সবকিছু বাতিল করতে পারে, বা এটি আরও ধীরে ধীরে প্রক্রিয়া করতে পারে, কারণ এটি শুধুমাত্র এই তিনটির জন্য অপ্টিমাইজ করা হয়েছে।

উদাহরণস্বরূপ, এই কারণেই কুইক, যার উপর ভিত্তি করে HTTP/3, UDP-এর উপরে তৈরি করা হয়েছিল, IP-এর উপরে নয়।

ঠিক আছে, যথেষ্ট শব্দ, এটি "বাস্তব জগতে" কীভাবে কাজ করে তা দেখার সময়।

যুদ্ধ

বাস্তব বিশ্বের অনুকরণ ব্যবহৃত iperf3. বাস্তবতার সাথে ঘনিষ্ঠতার ডিগ্রির পরিপ্রেক্ষিতে, এটি প্রায় মাইনক্রাফ্টে বাস্তব জগতের অনুকরণের সমান, তবে আপাতত এটি করবে।

প্রতিযোগিতায় অংশগ্রহণকারীরা:

• রেফারেন্স প্রধান চ্যানেল
• এই নিবন্ধের নায়ক ipipou
• প্রমাণীকরণ সহ OpenVPN কিন্তু কোন এনক্রিপশন নেই
• সব-অন্তর্ভুক্ত মোডে OpenVPN
• PresharedKey ছাড়া ওয়্যারগার্ড, MTU=1440 সহ (শুধুমাত্র IPv4 থেকে)

Geeks জন্য প্রযুক্তিগত তথ্য
মেট্রিক্স নিম্নলিখিত কমান্ডের সাথে নেওয়া হয়:

ক্লায়েন্টের উপর:

এর ফলে 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 চ্যানেল

চ্যানেল প্রতি 1 আশাবাদী Gbps

সব ক্ষেত্রে, ipipou বেস চ্যানেলের পারফরম্যান্সে বেশ কাছাকাছি, যা দুর্দান্ত!

এনক্রিপ্ট করা ওপেনভিপিএন টানেল উভয় ক্ষেত্রেই বেশ অদ্ভুতভাবে আচরণ করেছে।

যদি কেউ এটি পরীক্ষা করতে যাচ্ছে, এটি প্রতিক্রিয়া শুনতে আকর্ষণীয় হবে.

IPv6 এবং NetPrickle আমাদের সাথে থাকতে পারে!

উত্স: www.habr.com