🥇ipipou: फक्त एन्क्रिप्ट न केलेल्या बोगद्यापेक्षा अधिक

आम्ही IPv6 च्या देवाला काय म्हणत आहोत?

ते बरोबर आहे, आम्ही आज एन्क्रिप्शनच्या देवाला तेच म्हणू.

येथे आपण एनक्रिप्ट न केलेल्या IPv4 बोगद्याबद्दल बोलू, परंतु “उबदार दिवा” बद्दल नाही तर आधुनिक “LED” बद्दल बोलू. आणि येथे रॉ सॉकेट्स चमकत आहेत, आणि वापरकर्त्याच्या जागेत पॅकेट्ससह काम चालू आहे.

प्रत्येक चव आणि रंगासाठी एन टनेलिंग प्रोटोकॉल आहेत:

स्टाइलिश, फॅशनेबल, तरुण वायरगुर्ड
स्विस चाकू, OpenVPN आणि SSH सारखे मल्टीफंक्शनल
जुना आणि वाईट GRE नाही
सर्वात सोपा, जलद, पूर्णपणे कूटबद्ध न केलेला IPIP
सक्रियपणे विकसित होत आहे जिनेव्हा
इतर अनेक.

परंतु मी एक प्रोग्रामर आहे, म्हणून मी फक्त एका अंशाने N वाढवीन आणि वास्तविक प्रोटोकॉलचा विकास कॉमरसंट डेव्हलपरवर सोडेन.

एका अजन्मे मध्ये प्रकल्पमी आता जे करत आहे ते म्हणजे बाहेरून NAT च्या मागे असलेल्या यजमानांपर्यंत पोहोचणे. यासाठी प्रौढ क्रिप्टोग्राफीसह प्रोटोकॉल वापरून, मी तोफेतून चिमण्यांना गोळ्या घालण्यासारखे आहे ही भावना झटकून टाकू शकत नाही. कारण बोगद्याचा वापर बहुतेक भाग NAT-e मध्ये छिद्र पाडण्यासाठी केला जातो, अंतर्गत रहदारी सहसा एनक्रिप्टेड देखील असते, परंतु तरीही ते HTTPS मध्ये बुडतात.

विविध टनेलिंग प्रोटोकॉलचे संशोधन करत असताना, माझ्या आतील परफेक्शनिस्टचे लक्ष त्याच्या किमान ओव्हरहेडमुळे वारंवार IPIP कडे वेधले गेले. परंतु माझ्या कार्यांसाठी यात दीड महत्त्वपूर्ण कमतरता आहेत:

यासाठी दोन्ही बाजूंना सार्वजनिक IP आवश्यक आहेत,
आणि तुमच्यासाठी कोणतेही प्रमाणीकरण नाही.

म्हणून, परफेक्शनिस्टला परत कवटीच्या गडद कोपऱ्यात किंवा जिथे तो तिथे बसतो तिथे परत नेण्यात आला.

आणि मग एक दिवस, वर लेख वाचताना मूळ समर्थित बोगदे लिनक्समध्ये मला FOU (Foo-over-UDP) आढळले, म्हणजे. काहीही असो, UDP मध्ये गुंडाळलेले. आतापर्यंत, फक्त IPIP आणि GUE (जेनेरिक UDP एन्कॅप्सुलेशन) समर्थित आहेत.

“ही आहे चांदीची बुलेट! माझ्यासाठी एक साधा IPIP पुरेसा आहे.” - मला वाट्त.

खरं तर, बुलेट पूर्णपणे चांदीची नाही. UDP मधील एन्कॅप्सुलेशन पहिली समस्या सोडवते - तुम्ही पूर्व-स्थापित कनेक्शन वापरून बाहेरून NAT च्या मागे असलेल्या क्लायंटशी कनेक्ट करू शकता, परंतु येथे IPIP च्या पुढील दोषांपैकी अर्धा नवीन प्रकाशात उमलतो - खाजगी नेटवर्कमधील कोणीही दृश्याच्या मागे लपवू शकतो. सार्वजनिक IP आणि क्लायंट पोर्ट (शुद्ध IPIP मध्ये ही समस्या अस्तित्वात नाही).

या दीड समस्येचे निराकरण करण्यासाठी, उपयुक्तता जन्माला आली ipipou. हे कर्नल FOU च्या ऑपरेशनमध्ये व्यत्यय न आणता, रिमोट होस्ट ऑथेंटिकेट करण्यासाठी होममेड मेकॅनिझम लागू करते, जे कर्नल स्पेसमध्ये पॅकेट्सवर जलद आणि कार्यक्षमतेने प्रक्रिया करेल.

आम्हाला तुमच्या स्क्रिप्टची गरज नाही!

ठीक आहे, जर तुम्हाला क्लायंटचे सार्वजनिक पोर्ट आणि आयपी माहित असेल (उदाहरणार्थ, त्यामागील प्रत्येकजण कोठेही जात नाही, NAT 1-इन-1 पोर्ट्स मॅप करण्याचा प्रयत्न करतो), तुम्ही आयपीआयपी-ओव्हर-एफओयू बोगदा तयार करू शकता. कोणत्याही स्क्रिप्टशिवाय खालील आदेश.

सर्व्हरवर:

# Подгрузить модуль ядра 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 - क्लायंटचा सार्वजनिक IP
192.168.0.2 — क्लायंट IP इंटरफेस eth0 ला नियुक्त केले आहे
10001 - FOU साठी स्थानिक क्लायंट पोर्ट
20001 - FOU साठी सार्वजनिक क्लायंट पोर्ट
10000 - FOU साठी सार्वजनिक सर्व्हर पोर्ट
encap-csum — encapsulated UDP पॅकेटमध्ये UDP चेकसम जोडण्याचा पर्याय; द्वारे बदलले जाऊ शकते noencap-csum, उल्लेख नाही, अखंडता आधीच बाह्य एन्कॅप्सुलेशन लेयरद्वारे नियंत्रित केली जाते (पॅकेट बोगद्याच्या आत असताना)
eth0 — स्थानिक इंटरफेस ज्यामध्ये ipip बोगदा बांधला जाईल
172.28.0.1 — क्लायंट टनेल इंटरफेसचा IP (खाजगी)
172.28.0.0 — आयपी टनेल सर्व्हर इंटरफेस (खाजगी)

जोपर्यंत UDP कनेक्शन जिवंत आहे, तोपर्यंत बोगदा कार्यरत असेल, परंतु तो तुटल्यास, तुम्ही भाग्यवान असाल - जर क्लायंटचा IP: पोर्ट तसाच राहिला तर - तो जिवंत राहील, जर ते बदलला तर - तो खंडित होईल.

सर्व काही परत करण्याचा सर्वात सोपा मार्ग म्हणजे कर्नल मॉड्यूल्स अनलोड करणे: modprobe -r fou ipip

प्रमाणीकरणाची आवश्यकता नसली तरीही, क्लायंटचे सार्वजनिक IP आणि पोर्ट नेहमी ज्ञात नसतात आणि बहुतेक वेळा अप्रत्याशित किंवा परिवर्तनीय असतात (NAT प्रकारावर अवलंबून). आपण वगळल्यास encap-dport सर्व्हरच्या बाजूने, बोगदा कार्य करणार नाही, रिमोट कनेक्शन पोर्ट घेण्यास ते पुरेसे स्मार्ट नाही. या प्रकरणात, ipipou देखील मदत करू शकतात किंवा WireGuard आणि यासारखे इतर तुम्हाला मदत करू शकतात.

ते कसे कार्य करते?

क्लायंट (जे सहसा NAT च्या मागे असते) एक बोगदा उघडतो (वरील उदाहरणाप्रमाणे), आणि सर्व्हरला एक प्रमाणीकरण पॅकेट पाठवतो जेणेकरून तो त्याच्या बाजूला बोगदा कॉन्फिगर करेल. सेटिंग्जवर अवलंबून, हे रिकामे पॅकेट असू शकते (फक्त सर्व्हर सार्वजनिक IP: कनेक्शन पोर्ट पाहू शकतो), किंवा डेटा ज्याद्वारे सर्व्हर क्लायंट ओळखू शकतो. डेटा हा स्पष्ट मजकूरातील एक साधा सांकेतिक वाक्यांश असू शकतो (एचटीटीपी बेसिक ऑथशी साधर्म्य लक्षात येते) किंवा खाजगी की सह स्वाक्षरी केलेला खास डिझाइन केलेला डेटा असू शकतो (केवळ HTTP डायजेस्ट ऑथ प्रमाणेच, फंक्शन पहा client_auth कोडमध्ये).

सर्व्हरवर (सार्वजनिक IP असलेली बाजू), जेव्हा ipipou सुरू होते, तेव्हा ते nfqueue क्यू हँडलर तयार करते आणि नेटफिल्टर कॉन्फिगर करते जेणेकरुन आवश्यक पॅकेट जिथे असावे तिथे पाठवले जातील: nfqueue रांगेशी कनेक्शन सुरू करणारे पॅकेट, आणि [जवळजवळ] बाकीचे सर्व थेट श्रोता FOU कडे जातात.

ज्यांना माहिती नाही त्यांच्यासाठी, nfqueue (किंवा NetfilterQueue) ही कर्नल मॉड्यूल्स कशी विकसित करायची हे माहित नसलेल्या हौशींसाठी एक खास गोष्ट आहे, जे नेटफिल्टर (nftables/iptables) वापरून तुम्हाला नेटवर्क पॅकेट्स वापरकर्त्याच्या जागेवर पुनर्निर्देशित करू देते आणि तेथे वापरून त्यावर प्रक्रिया करू देते. आदिम अर्थ हाताशी आहे: सुधारित करा (पर्यायी) आणि ते कर्नलला परत द्या, किंवा टाकून द्या.

काही प्रोग्रामिंग भाषांसाठी nfqueue सह काम करण्यासाठी बंधने आहेत, bash साठी काहीही नव्हते (हे, आश्चर्यकारक नाही), मला पायथन वापरावे लागले: ipipou वापरते NetfilterQueue.

कार्यप्रदर्शन गंभीर नसल्यास, या गोष्टीचा वापर करून तुम्ही तुलनेने कमी स्तरावर पॅकेटसह कार्य करण्यासाठी तुमचे स्वतःचे तर्क तुलनेने जलद आणि सहजपणे तयार करू शकता, उदाहरणार्थ, प्रायोगिक डेटा ट्रान्सफर प्रोटोकॉल तयार करा किंवा अ-मानक वर्तनासह स्थानिक आणि दूरस्थ सेवा ट्रोल करा.

रॉ सॉकेट्स nfqueue सह हातात हात घालून काम करतात, उदाहरणार्थ, जेव्हा बोगदा आधीच कॉन्फिगर केलेला असेल आणि FOU इच्छित पोर्टवर ऐकत असेल, तेव्हा तुम्ही त्याच पोर्टवरून नेहमीच्या पद्धतीने पॅकेट पाठवू शकणार नाही - ते व्यस्त आहे, परंतु तुम्ही रॉ सॉकेट वापरून यादृच्छिकपणे व्युत्पन्न केलेले पॅकेट थेट नेटवर्क इंटरफेसवर घेऊ शकता आणि पाठवू शकता, जरी असे पॅकेट तयार करण्यासाठी थोडे अधिक टिंकरिंग आवश्यक असेल. अशा प्रकारे ipipou मध्ये प्रमाणीकरण असलेले पॅकेट तयार केले जातात.

ipipou कनेक्शनमधील फक्त पहिल्या पॅकेटवर प्रक्रिया करत असल्याने (आणि कनेक्शन स्थापित होण्यापूर्वी रांगेत गळती करण्यात व्यवस्थापित केलेले), कार्यप्रदर्शन जवळजवळ प्रभावित होत नाही.

ipipou सर्व्हरला प्रमाणीकृत पॅकेट प्राप्त होताच, एक बोगदा तयार केला जातो आणि कनेक्शनमधील सर्व पुढील पॅकेट्स nfqueue बायपास करून कर्नलद्वारे आधीच प्रक्रिया केली जातात. कनेक्शन अयशस्वी झाल्यास, नंतरचे पहिले पॅकेट nfqueue रांगेत पाठवले जाईल, सेटिंग्जवर अवलंबून, जर ते प्रमाणीकरण असलेले पॅकेट नसेल, परंतु शेवटच्या लक्षात ठेवलेल्या IP आणि क्लायंट पोर्टवरून, ते एकतर पास केले जाऊ शकते. चालू किंवा टाकून दिले. नवीन आयपी आणि पोर्टवरून प्रमाणीकृत पॅकेट आल्यास, ते वापरण्यासाठी बोगदा पुन्हा कॉन्फिगर केला जातो.

NAT सोबत काम करताना नेहमीच्या IPIP-over-FOU मध्ये आणखी एक समस्या असते - UDP मध्ये एकाच IP सह दोन IPIP बोगदे तयार करणे अशक्य आहे, कारण FOU आणि IPIP मॉड्यूल एकमेकांपासून पूर्णपणे वेगळे आहेत. त्या. समान सार्वजनिक IP च्या मागे असलेल्या क्लायंटची जोडी अशा प्रकारे एकाच सर्व्हरशी एकाच वेळी कनेक्ट होऊ शकणार नाही. भविष्यात, कदाचित, हे कर्नल स्तरावर सोडवले जाईल, परंतु हे निश्चित नाही. यादरम्यान, NAT समस्या NAT द्वारे सोडवल्या जाऊ शकतात - जर असे घडले की IP पत्त्यांची जोडी आधीच दुसर्या बोगद्याने व्यापलेली असेल तर, ipipou सार्वजनिक पासून NAT पर्यायी खाजगी IP वर करेल, voila! - पोर्ट संपेपर्यंत तुम्ही बोगदे तयार करू शकता.

कारण कनेक्शनमधील सर्व पॅकेट्सवर स्वाक्षरी केलेली नाही, तर हे साधे संरक्षण एमआयटीएमसाठी असुरक्षित आहे, म्हणून जर क्लायंट आणि सर्व्हर दरम्यानच्या मार्गावर एखादा खलनायक लपलेला असेल जो ट्रॅफिक ऐकू शकतो आणि त्यात फेरफार करू शकतो, तो प्रमाणित पॅकेट्स याद्वारे पुनर्निर्देशित करू शकतो. दुसरा पत्ता आणि अविश्वासू होस्टकडून एक बोगदा तयार करा.

मोठ्या प्रमाणात रहदारी सोडताना याचे निराकरण कसे करावे याबद्दल कोणाला कल्पना असल्यास, बोलण्यास अजिबात संकोच करू नका.

तसे, UDP मध्ये encapsulation स्वतःला खूप चांगले सिद्ध केले आहे. IP वर एन्कॅप्सुलेशनच्या तुलनेत, UDP हेडरचे अतिरिक्त ओव्हरहेड असूनही ते अधिक स्थिर आणि बरेचदा जलद आहे. हे या वस्तुस्थितीमुळे आहे की इंटरनेटवरील बहुतेक होस्ट केवळ तीन सर्वात लोकप्रिय प्रोटोकॉलसह चांगले कार्य करतात: TCP, UDP, ICMP. मूर्त भाग इतर सर्व गोष्टी पूर्णपणे काढून टाकू शकतो किंवा त्यावर अधिक हळूहळू प्रक्रिया करू शकतो, कारण तो फक्त या तिघांसाठीच अनुकूल आहे.

उदाहरणार्थ, म्हणूनच क्विक, ज्यावर HTTP/3 आधारित आहे, UDP च्या शीर्षस्थानी तयार केले गेले आहे, IP च्या शीर्षस्थानी नाही.

बरं, पुरेसे शब्द, "वास्तविक जगात" ते कसे कार्य करते हे पाहण्याची वेळ आली आहे.

लढाई

वास्तविक जगाचे अनुकरण करण्यासाठी वापरले जाते 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", чтобы лишние пакеты не плодить и не портить производительность.

टीसीपी

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 बेस चॅनेलच्या कार्यक्षमतेच्या अगदी जवळ आहे, जे उत्तम आहे!

एनक्रिप्टेड ओपनव्हीपीएन बोगदा दोन्ही प्रकरणांमध्ये विचित्रपणे वागला.

जर कोणी त्याची चाचणी घेणार असेल तर प्रतिक्रिया ऐकणे मनोरंजक असेल.

IPv6 आणि NetPrickle आमच्यासोबत असू द्या!

स्त्रोत: www.habr.com

ipipou: फक्त एक अनएनक्रिप्टेड बोगद्यापेक्षा अधिक

आम्हाला तुमच्या स्क्रिप्टची गरज नाही!

ते कसे कार्य करते?

लढाई

बोगदा कॉन्फिगरेशन

निकाल

एक टिप्पणी जोडा Отменить ответ