🥇ipipou: एन्क्रिप्ट नगरिएको सुरुङ मात्र भन्दा बढी

हामी IPv6 को भगवानलाई के भनिरहेका छौं?

त्यो ठीक छ, हामी आज इन्क्रिप्शनको देवतालाई पनि भन्नेछौं।

यहाँ हामी एन्क्रिप्ट नगरिएको IPv4 सुरुङको बारेमा कुरा गर्नेछौं, तर "न्यानो बत्ती" को बारेमा होइन, तर आधुनिक "LED" को बारेमा। र यहाँ कच्चा सकेटहरू पनि फ्ल्यासिङ छन्, र प्रयोगकर्ता स्पेसमा प्याकेटहरूसँग काम भइरहेको छ।

त्यहाँ प्रत्येक स्वाद र रंगको लागि N टनेलिङ प्रोटोकलहरू छन्:

स्टाइलिश, फैशनेबल, युवा WireGuard
बहुकार्यात्मक, जस्तै स्विस चाकू, OpenVPN र SSH
पुरानो र खराब GRE होइन
सबैभन्दा सरल, छिटो, पूर्ण रूपमा एन्क्रिप्ट नगरिएको IPIP
सक्रिय रूपमा विकास गर्दै GENEVE
धेरै अन्य।

तर म एक प्रोग्रामर हुँ, त्यसैले म N को एक अंशले मात्र बढाउनेछु, र वास्तविक प्रोटोकलहरूको विकास Kommersant विकासकर्ताहरूलाई छोड्नेछु।

एउटा नजन्ममा ड्राफ्टम अहिले के गरिरहेको छु बाहिरबाट NAT पछाडि होस्टहरू पुग्नु हो। यसको लागि वयस्क क्रिप्टोग्राफीको साथ प्रोटोकलहरू प्रयोग गरेर, मैले यो तोपबाट भँगेरालाई गोली हानेजस्तै हो भन्ने भावनालाई हल्लाउन सकिन। किनभने NAT-e मा प्वालहरू पोक गर्नको लागि मात्र सुरुङ प्रयोग गरिन्छ, आन्तरिक ट्राफिक सामान्यतया इन्क्रिप्टेड हुन्छ, तर तिनीहरू अझै पनि HTTPS मा डुब्छन्।

विभिन्न टनेलिङ प्रोटोकलहरू अनुसन्धान गर्दा, मेरो भित्री पूर्णतावादीको ध्यान यसको न्यूनतम ओभरहेडको कारणले बारम्बार IPIP तिर खिचियो। तर यसमा मेरो कार्यहरूको लागि डेढ महत्त्वपूर्ण कमजोरीहरू छन्:

यसलाई दुबै पक्षमा सार्वजनिक आईपीहरू चाहिन्छ,
र तपाईंको लागि कुनै प्रमाणीकरण छैन।

त्यसकारण, पूर्णतावादीलाई खोपडीको अँध्यारो कुनामा, वा जहाँ पनि ऊ त्यहाँ बस्छ, फर्काइयो।

अनि एक दिन, लेख पढ्दै गर्दा मूल रूपमा समर्थित सुरुङहरू लिनक्समा मैले FOU (Foo-over-UDP) भेटें, अर्थात्। जे होस्, UDP मा बेरिएको। अहिलेसम्म, IPIP र GUE (जेनेरिक UDP इन्क्याप्सुलेशन) मात्र समर्थित छन्।

"यहाँ चाँदीको गोली छ! एक साधारण 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 - सार्वजनिक आईपी सर्भर
198.51.100.2 - ग्राहकको सार्वजनिक आईपी
192.168.0.2 - ग्राहक आईपी इन्टरफेस eth0 मा तोकिएको छ
10001 - FOU को लागि स्थानीय ग्राहक पोर्ट
20001 - FOU को लागि सार्वजनिक ग्राहक पोर्ट
10000 - FOU को लागि सार्वजनिक सर्भर पोर्ट
encap-csum - encapsulated UDP प्याकेटहरूमा UDP चेकसम थप्ने विकल्प; द्वारा प्रतिस्थापन गर्न सकिन्छ noencap-csum, उल्लेख नगर्न, अखण्डता पहिले नै बाहिरी encapsulation तह द्वारा नियन्त्रित छ (जबकि प्याकेट सुरुङ भित्र छ)
eth0 — स्थानीय इन्टरफेस जसमा ipip सुरुङ बाँधिएको हुनेछ
172.28.0.1 - ग्राहक टनेल इन्टरफेसको आईपी (निजी)
172.28.0.0 - आईपी टनेल सर्भर इन्टरफेस (निजी)

जबसम्म UDP जडान जीवित छ, सुरुङ कार्य क्रममा हुनेछ, तर यदि यो बिच्छेद भयो भने, तपाईं भाग्यशाली हुनुहुनेछ - यदि ग्राहकको IP: पोर्ट उस्तै रहन्छ - यो जीवित हुनेछ, यदि तिनीहरू परिवर्तन भएमा - यो फुट्नेछ।

सबै कुरा फिर्ता गर्ने सबैभन्दा सजिलो तरिका कर्नेल मोड्युलहरू अनलोड गर्नु हो: modprobe -r fou ipip

प्रमाणीकरण आवश्यक नभए पनि, क्लाइन्टको सार्वजनिक आईपी र पोर्ट सधैं थाहा हुँदैन र प्रायः अप्रत्याशित वा चर हुन्छन् (NAT प्रकारको आधारमा)। यदि तपाईंले छोड्नुभयो भने encap-dport सर्भर साइडमा, सुरुङले काम गर्दैन, यो रिमोट जडान पोर्ट लिन पर्याप्त स्मार्ट छैन। यस अवस्थामा, ipipou ले पनि मद्दत गर्न सक्छ, वा WireGuard र अरू जस्तै यसले तपाईंलाई मद्दत गर्न सक्छ।

यसले कसरी काम गर्छ?

क्लाइन्ट (जुन सामान्यतया NAT पछाडि छ) एक सुरुङ खोल्छ (माथिको उदाहरणमा जस्तै), र सर्भरमा प्रमाणीकरण प्याकेट पठाउँदछ ताकि यसले यसको छेउमा टनेल कन्फिगर गर्दछ। सेटिङ्हरूमा निर्भर गर्दै, यो खाली प्याकेट हुन सक्छ (केवल ताकि सर्भरले सार्वजनिक आईपी: जडान पोर्ट देख्न सक्छ), वा डाटा जसद्वारा सर्भरले ग्राहक पहिचान गर्न सक्छ। डाटा स्पष्ट पाठमा एक साधारण पासफ्रेज हुन सक्छ (HTTP आधारभूत प्रमाणसँग समानता दिमागमा आउँछ) वा निजी कुञ्जीसँग हस्ताक्षर गरिएको विशेष रूपमा डिजाइन गरिएको डाटा (HTTP डाइजेस्ट प्रमाणीकरण मात्र बलियो जस्तै, प्रकार्य हेर्नुहोस्। client_auth कोडमा)।

सर्भरमा (सार्वजनिक आईपीको छेउमा), जब ipipou सुरु हुन्छ, यसले nfqueue क्यु ह्यान्डलर सिर्जना गर्दछ र नेटफिल्टर कन्फिगर गर्दछ ताकि आवश्यक प्याकेटहरू जहाँ हुनुपर्छ त्यहाँ पठाइन्छ: प्याकेटहरू nfqueue लाममा जडान सुरु गर्दै, र [लगभग] बाँकी सबै सिधै श्रोता FOU मा जान्छन्।

थाहा नभएकाहरूका लागि, nfqueue (वा NetfilterQueue) कर्नेल मोड्युलहरू कसरी विकास गर्ने भनेर थाहा नभएका एमेच्योरहरूका लागि विशेष कुरा हो, जसले नेटफिल्टर (nftables/iptables) को प्रयोग गरेर तपाईंलाई नेटवर्क प्याकेटहरू प्रयोगकर्ता स्पेसमा रिडिरेक्ट गर्न र त्यहाँ प्रयोग गरेर तिनीहरूलाई प्रशोधन गर्न अनुमति दिन्छ। आदिम अर्थ हातमा छ: परिमार्जन गर्नुहोस् (वैकल्पिक) र यसलाई कर्नेलमा फिर्ता दिनुहोस्, वा खारेज गर्नुहोस्।

केही प्रोग्रामिङ भाषाहरूको लागि त्यहाँ nfqueue सँग काम गर्नका लागि बाइन्डिङहरू छन्, bash को लागि त्यहाँ कुनै पनि थिएन (हे, अचम्मको कुरा होइन), मैले python प्रयोग गर्नुपर्‍यो: ipipou प्रयोग गर्दछ। NetfilterQueue.

यदि कार्यसम्पादन महत्वपूर्ण छैन भने, यो चीज प्रयोग गरेर तपाईले अपेक्षाकृत कम स्तरमा प्याकेटहरूसँग काम गर्नको लागि आफ्नो तर्कलाई तुलनात्मक रूपमा छिटो र सजिलै संग बनाउन सक्नुहुन्छ, उदाहरणका लागि, प्रयोगात्मक डेटा स्थानान्तरण प्रोटोकलहरू सिर्जना गर्नुहोस्, वा गैर-मानक व्यवहारको साथ स्थानीय र रिमोट सेवाहरू ट्रोल गर्नुहोस्।

कच्चा सकेटहरू nfqueue सँग हातमा हात मिलाएर काम गर्छन्, उदाहरणका लागि, जब सुरुङ पहिले नै कन्फिगर गरिएको छ र FOU ले इच्छित पोर्टमा सुनिरहेको छ, तपाईंले सामान्य रूपमा उही पोर्टबाट प्याकेट पठाउन सक्षम हुनुहुने छैन - यो व्यस्त छ, तर तपाईले कच्चा सकेट प्रयोग गरेर अनियमित रूपमा उत्पन्न गरिएको प्याकेट सीधै नेटवर्क इन्टरफेसमा पठाउन सक्नुहुन्छ, यद्यपि यस्तो प्याकेट उत्पन्न गर्न अलि बढी टिंकरिङ आवश्यक पर्दछ। यसरी ipipou मा प्रमाणीकरण भएको प्याकेटहरू सिर्जना गरिन्छन्।

किनकि ipipou ले जडानबाट पहिलो प्याकेटहरू मात्र प्रशोधन गर्दछ (र जडान स्थापना हुनु अघि लाममा चुहावट गर्न व्यवस्थित), कार्यसम्पादन लगभग प्रभावित हुँदैन।

ipipou सर्भरले प्रमाणीकृत प्याकेट प्राप्त गर्ने बित्तिकै, एउटा सुरुङ सिर्जना हुन्छ र जडानमा रहेका सबै पछिल्ला प्याकेटहरू पहिले नै कर्नेलद्वारा nfqueue लाई बाइपास गरेर प्रशोधन गरिन्छ। यदि जडान असफल भयो भने, त्यसपछि अर्कोको पहिलो प्याकेट nfqueue लाममा पठाइनेछ, सेटिङहरूमा निर्भर गर्दछ, यदि यो प्रमाणीकरणको साथ प्याकेट होइन, तर अन्तिम सम्झना IP र ग्राहक पोर्टबाट, यसलाई या त पारित गर्न सकिन्छ। मा वा खारेज। यदि एक प्रमाणीकृत प्याकेट नयाँ आईपी र पोर्टबाट आउँछ भने, टनेल तिनीहरूलाई प्रयोग गर्न पुन: कन्फिगर गरिएको छ।

NAT सँग काम गर्दा सामान्य IPIP-over-FOU मा अर्को समस्या छ - UDP मा एउटै IP संग इनक्याप्सुलेटेड दुई IPIP टनेलहरू सिर्जना गर्न असम्भव छ, किनभने FOU र IPIP मोड्युलहरू एकअर्काबाट एकदम अलग छन्। ती। एउटै सार्वजनिक आईपी पछि ग्राहकहरूको एक जोडी यस तरिकाले एउटै सर्भरमा एकसाथ जडान गर्न सक्षम हुनेछैन। भविष्यमा, सम्भवतः, यो कर्नेल स्तर मा हल हुनेछ, तर यो निश्चित छैन। यस बीचमा, NAT समस्याहरू NAT द्वारा हल गर्न सकिन्छ - यदि यो हुन्छ कि IP ठेगानाहरूको एक जोडी पहिले नै अर्को सुरुङ द्वारा कब्जा गरिएको छ भने, ipipou ले NAT लाई सार्वजनिकबाट वैकल्पिक निजी IP मा गर्नेछ, voila! - पोर्टहरू समाप्त नभएसम्म तपाइँ सुरुङहरू सिर्जना गर्न सक्नुहुन्छ।

किनभने जडानमा सबै प्याकेटहरू हस्ताक्षरित छैनन्, तब यो साधारण सुरक्षा MITM को लागी कमजोर छ, त्यसैले यदि ग्राहक र सर्भर बीचको बाटोमा खलनायक लुकेको छ जसले ट्राफिक सुन्न सक्छ र यसलाई हेरफेर गर्न सक्छ, उसले प्रमाणीकृत प्याकेटहरू पुन: निर्देशित गर्न सक्छ। अर्को ठेगाना र अविश्वसनीय होस्टबाट सुरुङ सिर्जना गर्नुहोस्।

यदि कोहीसँग मुख्य ट्राफिकको ठूलो भाग छोड्दा यसलाई कसरी समाधान गर्ने भन्ने बारे विचार छ भने, बोल्न नहिचकिचाउनुहोस्।

वैसे, UDP मा encapsulation ले आफैलाई धेरै राम्रो साबित गरेको छ। IP मा encapsulation को तुलनामा, UDP हेडर को अतिरिक्त ओभरहेड को बावजुद यो धेरै अधिक स्थिर र अक्सर छिटो छ। यो तथ्यको कारण हो कि इन्टरनेटमा धेरै होस्टहरूले केवल तीन सबैभन्दा लोकप्रिय प्रोटोकलहरूसँग राम्रोसँग काम गर्छन्: TCP, UDP, ICMP। मूर्त भागले अरू सबै कुरालाई पूर्ण रूपमा खारेज गर्न सक्छ, वा यसलाई अझ बिस्तारै प्रशोधन गर्न सक्छ, किनभने यो यी तीनका लागि मात्र अनुकूलित छ।

उदाहरणका लागि, यही कारणले गर्दा क्विक, जसमा HTTP/3 आधारित छ, UDP को शीर्षमा सिर्जना गरिएको थियो, IP को शीर्षमा होइन।

ठीक छ, पर्याप्त शब्दहरू, यो "वास्तविक संसार" मा कसरी काम गर्दछ भनेर हेर्नको लागि समय हो।

युद्ध

वास्तविक संसारको अनुकरण गर्न प्रयोग गरियो iperf3। वास्तविकताको नजिकको डिग्रीको सन्दर्भमा, यो लगभग Minecraft मा वास्तविक संसारको अनुकरण गर्ने जस्तै हो, तर अहिलेको लागि यो गर्नेछ।

प्रतियोगितामा सहभागीहरु:

सन्दर्भ मुख्य च्यानल
यस लेखको नायक ipipou हो
प्रमाणीकरणको साथ OpenVPN तर कुनै एन्क्रिप्शन छैन
OpenVPN सबै समावेशी मोडमा
PresharedKey बिना WireGuard, 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", чтобы лишние пакеты не плодить и не портить производительность.

टीसीपी

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"

टीसीपी

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 आधार च्यानलको प्रदर्शनमा धेरै नजिक छ, जुन उत्कृष्ट छ!

अनइन्क्रिप्टेड openvpn टनेलले दुवै अवस्थामा धेरै अनौठो व्यवहार गर्यो।

यदि कसैले यसलाई परीक्षण गर्न जाँदै हुनुहुन्छ भने, यो प्रतिक्रिया सुन्न रोचक हुनेछ।

IPv6 र NetPrickle हामीसँग हुन सक्छ!

स्रोत: www.habr.com

ipipou: केवल एक एन्क्रिप्टेड सुरुङ भन्दा बढी

हामीलाई तपाईंको स्क्रिप्ट चाहिँदैन!

यसले कसरी काम गर्छ?

युद्ध

टनेल कन्फिगरेसन

Результаты

एक टिप्पणी थप्न Отменить ответ