نحن نعيش في وقت مثير للاهتمام. أود أن أقول بطرق مذهلة. من جهة ، نرى بعض الأشخاص الذين يريدون حقًا معرفة ما يتحدثه الآخرون مع بعضهم البعض ، ويريدون حقًا إخبارهم بما يمكن قراءته وما لا يمكن قراءته. من ناحية أخرى ، المواطنون الذين يريدون التأكيد على حقوقهم في أسرار المراسلات الشخصية والمعلومات المجانية ، ولا يريدون استخدام حقائق هذه المراسلات واستلام هذه المعلومات ضدهم. يعاني عدد كبير من مواقع وخدمات وشركات الطرف الثالث التي تتعرض "لأقفال السجاد" كمكافأة.
لكن لا ، هذه المقالة ليست عن المجتمع ، بل عن التكنولوجيا.

إن محو الأمية التقنية للناس ، بفضل كل ما يحدث ، ينمو أيضًا. إذا كانت الكلمات "VPN" و "الوكلاء" في وقت سابق مألوفة فقط لمتخصصي تكنولوجيا المعلومات ، فإن ربات البيوت الآن يعرفونهم ، علاوة على ذلك ، يستخدمون ما تعنيه هذه الكلمات.
بشكل عام ، جاءت الأخبار مؤخرًا مسلية للغاية. على سبيل المثال ، يعد تقديم خدمات VPN وما شابه ذلك لتشفير حركة المرور وتجاوز الأقفال أمرًا خاضعًا
للعقاب ، وفي الصين عادة ما
يسجنهم بسبب ذلك. ومنذ وقت ليس ببعيد ، بدأت ILV في استخدام
تحليل الحزمة لمنع بروتوكول MTProxy. يمكنك أيضًا الرجوع إلى تجربة الدول الأخرى الأكثر نجاحًا في مثل هذه الأمور: الصين وإيران وكازاخستان وفنزويلا. في فنزويلا ، على سبيل المثال ، قاموا مباشرة
بحظر الاتصالات المباشرة
بتور وحجب حركة المرور إلى الجسور. بناءً على كل هذا ، يمكننا أن نفترض أن المستقبل الذي ينتظرنا هو أيضًا مثير للاهتمام للغاية ، خاصة إذا توقف "الأشخاص المسؤولون" عن صنع فاكابي غبي مرارًا وتكرارًا ، وتصرفوا بشكل أكثر ذكاءً وتعقيدًا.
عبر حبري مرارا وتكرارا في التعليقات عبر عن توقعات لكيفية استمرار الصراع مع تقنيات التشفير للمواطنين العاديين. عند تحليل الأفكار المعبر عنها والنظر في شهادات من دول أخرى ، حاولت أن أقترح في أي اتجاه يمكن أن تتحرك التدابير للحد من التواصل أكثر.
طرح DistortNeo و
shifttstas بعض الأفكار الأكثر إثارة للاهتمام ، وفي النهاية وعدت
el777 بإضافة هذه المقالة.
مع مرشحات ACL ، كل شيء واضح. إنهم يتصرفون الآن ، وبنجاح متفاوت ينجحون ويفشلون في القتال (على الرغم من وجود
توقعات متشائمة للغاية). DPI أكثر إثارة للاهتمام.
يمكن تقسيم طرق "تحديد" نوع حركة المرور لكل نقطة لكل بوصة إلى مجموعتين:
- تحليل التوقيع. وهي تفكيك العبوة "بالعظام" ، ومقارنة الرؤوس والهيكل بالعينات ، وبالتالي تحديد الغرض منها. وبالتالي ، تم الكشف عن العديد من الأنفاق ، على سبيل المثال ، OpenVPN ، L2TP / IPSec ، SOCKS ، إلخ.
- إن التحليل الأولي لأنماط تبادل الحركة ، على سبيل المثال ، نسبة التدفق الوارد / الصادر ، وتواتر الاستجابة للطلبات وغيرها من المعايير سيسمح لنا بفصل "الحركة الحقيقية" للبروتوكول والنفق الذي يتنكر فقط كبروتوكول.

يمكنك تقسيم حركة المرور إلى عدة مجموعات وافتراض ما ستفعله مع كل منها.
- شبكات VPN والأنفاق والوكلاء "الصريحة" (OpenVPN و L2TP / IPSec و SOCKS وما إلى ذلك) قد يتم حظر شبكات VPN والأنفاق العادية تلقائيًا ، على سبيل المثال ، يحدث هذا في الصين وفنزويلا. إذا كانت بعض المنظمات أو الشركات بحاجة إليها للعمل ، فدعها تسجل وتصدق ، كما يتحدث القانون الروسي المذكور أعلاه بشكل خاص. باستخدام الوكيل ، من الأسهل - أن HTTP ، الذي تقوم SOCKS بنقل العناوين والمحتويات بنص واضح ، والذي لا يخلق بشكل عام أي مشاكل لـ "قطع" انتقائي للطلبات والتنصت على المعلومات المرسلة.
- التقنيات ذات الاستخدام المزدوج مثل SSH . بعد وقت قصير من إنشاء الجلسة ، يتم قطع السرعة إلى سلحفاة ، بحيث لا يزال بإمكانك العمل بطريقة أو بأخرى على الأقل في وحدة التحكم ، ولكن لم يعد هناك المزيد من التصفح والتنزيل. حقيقة أن هذا يخلق مشاكل أثناء العمل العادي لا يزعج أي شخص (والذي أظهره لنا ILV أكثر من مرة في الآونة الأخيرة).
- بروتوكولات محددة للغاية ، مثل برامج المراسلة وعملاء الألعاب ، إلخ.
- المركبات التي لا يمكن تحديد نوعها .
بالنسبة للبندين 3 و 4 ، فإن "القوائم البيضاء" ممكنة تمامًا (حيث يتم ، على سبيل المثال ، إدخال شبكات فرعية من خوادم الألعاب الرسمية أو رسل "صحيحة" ، وكل ما يريد أصحاب الخوادم إعلانه وترتيبه حسب الضرورة حتى لا يتم لمسهم ، عن طريق القياس مع تلك التي لديها ILV بالفعل للمجالات وعناوين IP). وسيواجه أولئك الذين ليسوا في هذه القوائم نفس مصير الفقرة 1 أو الفقرة 2 ، على الرغم من أنه من الممكن تمامًا عدم حظر السرعة أو قطعها ، ولكن تحليل أنماط التبادل المذكورة سابقًا لتحديد ما إذا كانت حركة المرور "نقية" "أو" المشبوهة. "
بمعنى ، إذا كنت تريد إخفاء نفسك كبروتوكولات خاصة ، أو تشويش الاتصالات بحيث يكون من المستحيل تحديد نوعها ، سيتعين عليك أيضًا الاهتمام بإنشاء "ضوضاء" تمنع اكتشاف أنماط التبادل الحقيقية. حتى الآن ، لم تظهر مثل هذه التطورات في نظري.
لا يمكنك حتى أن تتذكر أنفاق ICMP و DNS المختلفة - كما أن كمية كبيرة من حركة المرور "عند عدم الحاجة إليها" تثير الشكوك تلقائيًا.
5.
TLS و SSL و HTTPS . من المستحيل قطع النظافة ، لأن هذا يعني تلقائيًا حظر الإنترنت بالكامل. تحليل الأنماط لا معنى له ، لأن تصفح الويب هو فقط الغرض الرئيسي من استخدام HTTPS. من كل ما سبق ، يبدو أن SSL / TLS على المنفذ 443 هو الخيار الأكثر "موثوقية" والأكثر موثوقية. لذلك ، دعونا نحاول إخفاء أنفسنا مثله.

تمويه أنفسنا
للنظر ، تقرر اختيار حلول Streisand و SoftEther.
Streisand - مجموعة كاملة من الخدمات المختلفة: OpenConnect / AnyConnect و OpenVPN و stunnel و Shadowsocks و WireGuard. يتم تعيين كل هذا في وضع "تسليم المفتاح" التلقائي أو شبه التلقائي ، وعند الإخراج يتلقى المستخدم خادمًا تم تكوينه ، بالإضافة إلى الملفات والوثائق التفصيلية لإعداد العملاء.
SoftEther هو خادم VPN يمكنه رفع L2TP / IPsec و OpenVPN و SSTP والبروتوكولات الأخرى ، ولديه أيضًا بروتوكول SSL-VPN الخاص به ، والذي ، وفقًا للمؤلفين ، لا يمكن تمييزه عن حركة مرور HTTPS العادية.
لذا ...
OpenConnect / AnyConnect. تنفيذ مفتوح المصدر لبروتوكول Cisco AnyConnect SSL. عند إنشاء اتصال ، لن تكون حزم TLS (TCP) فقط ، ولكن أيضًا حزم DTLS (UDP) مرئية. DTLS ، من حيث المبدأ ، يستخدم أيضًا كثيرًا "للأغراض السلمية" ، ولكن هذا ليس مثل "HTTPS العادي" على الإطلاق. ومع ذلك ، إذا قمت بقطع حركة مرور UDP على جدار الحماية ، فإن AnyConnect يتحول على الفور إلى TCP ومن المظهر الخارجي ، مرة أخرى ، تمامًا تمامًا مثل TLS العادي ، وحتى المصادقة داخل النفق المشفر تشبه تقريبًا HTTP.
شادوسوكس . وكيل SOCKS المشفرة. على ما يبدو ، إذا رغبت في ذلك ،
يمكن اكتشافه ، ومع ذلك ، هناك مكونات إضافية
تخفيها على أنها "HTTPS خالص" . هناك أيضًا
مكون إضافي للعمل من خلال websockets ، ولكن المزيد عن ذلك لاحقًا.
حارس الأسلاك إذا حكمنا من خلال الوصف ، فإنه يحتوي على تشفير ملتوي بشكل جيد وآلية إعداد الجلسة ، ولكن كل الاتصالات تتم عبر UDP. يعرّف Wireshark نوع الحزم على أنه شيء غير مسموع تمامًا ، وما هو رأي حول ما يحدث مع طرف ثالث DPI هو سؤال كبير جدًا.
التحديث: تحدد الإصدارات الأحدث Wireguard بشكل فريد على أنها Wireguard ، لذا فإن إجابة السؤال واضحة.
obfs3 ، obfs4 . سيتم تعتيم الحزم بحيث تبدو من الخارج كمجموعة عشوائية تمامًا من القيم. أي أنها تندرج تحت البند 4 من القائمة أعلاه.
سوفتثير يبدو HTTPS ، ولكن مع صيد واحد. بالإضافة إلى TLS مباشرة عبر TCP ، فإنه يرسل حزم حزم UDP بنشاط. كما تم العثور عليه في الوثائق ، يمكن استخدام UDP لتسريع نقل البيانات في حالة عدم قتلها على جدار الحماية. يتم تعطيل هذه الوظيفة في التكوين ، وبعد تعطيلها ، يصبح كل شيء كما ينبغي.
SSTP . prokotol VPN من Microsoft. مدعوم أصلاً على Windows ، ويدعم البرنامج على GNU / Linux. من الخارج يبدو أنه HTTPS ، ويؤكد Wireshark ذلك تمامًا.
لكن هذا ليس كل شيء
افترض أنك قمت بتثبيت خادم VPN أو نهاية نفق على مضيف وقمت بتكوينه للاستماع على المنفذ 443. يبدو أن كل شيء على ما يرام ، ولكن هناك واحد ولكن: إذا تمويه أنفسنا على أنه HTTPS ، يمكنك التحقق من أنه في الواقع معلق على المنفذ 443 ببساطة عن طريق محاولة دفن نفسك في هذا المنفذ باستخدام متصفح بسيط أو CURL ، أو بأي طريقة أخرى. في بعض المقالات ، تسمى هذه الطريقة "الاتصال الرئيسي" ، وكما ذكرنا ، يتم استخدامها بالفعل في الصين.
لذلك ، نحتاج إلى أنه في المنفذ 443 لدينا خادم الويب الأكثر عادية ولائقة. وهنا تنشأ مشكلة مثيرة للاهتمام.
لم تجد أي من الخدمات المذكورة أعلاه في الوثائق الرئيسية وصفاً لآلية العمل لتقاسم المنافذ.
خيار SSLH غير مناسب ، فقط إذا كان SSLH غير قادر على مشاركة حركة المرور بين HTTPS والخدمات المذكورة أعلاه. على الأقل ، لأنه إذا كان نوع حركة المرور بدون فك التشفير الكامل يمكن أن يميز SSLH ، فسيكون DPI قادرًا على ذلك.
يقترح معظم الرجال ، مثل
هذا ، استخدام إشارة اسم الخادم (SNI) - امتداد TLS الذي يسمح لك بتحديد اسم مضيف ، ثم استخدام HAProxy و sniproxy وغيرها من الأدوات لتوزيع الاتصالات للخدمات. تكمن المشكلة في أنه في تطبيقات TLS الحديثة ، يتم إرسال اسم المضيف المحدد عند استخدام SNI في نص عادي ، أي في شكل غير مشفر ، وبالتالي ، يمكن أيضًا التجسس عليه واستخدامه في المستقبل.
لذلك ، سوف نرتجل ، ثم يتبادر إلى ذهني خياران.
طرق الميناء

تم تصميم قرع المنفذ لتفعيل "الخدمات المخفية" على الخادم. على سبيل المثال ، بطريقة مماثلة ، غالبًا ما يتم إغلاق المنفذ الذي يتم تعليق خدمة SSH عليه "لتجنب" القوة الغاشمة واستخدام ثغرات 0 يومًا. في الإصدار الكلاسيكي (انظر ، على سبيل المثال ، تنفيذ برنامج knockd) ، يُفهم الطرق عادةً على أنه محاولات لإنشاء اتصال أو إرسال حزم إلى منافذ مضيف محددة في تسلسل معين ، ونتيجة لذلك "يتعرف" البرنامج الخفي على أنك ملكه وينشط قاعدة جدار الحماية التي تسمح بالوصول إلى منفذ معين فقط من IP الخاص بك.
في حالتنا ، هذا الخيار غير مقبول تمامًا. أولاً ، قد يتم حظر المنافذ "غير القياسية" نفسها في مكان ما على طول الطريق ، وثانيًا ، قد يبدو الإجراء نفسه ، عند تحليله من الخارج ، مريبًا. نظرًا لأننا نتنكر على شكل HTTPS ، فإننا بحاجة إلى "طرق" على HTTPS.
والمثير للدهشة ، أنه لم يكن هناك مقارع HTTP / HTTPS مع الوظائف المطلوبة ، وبالتالي ولد
nocker بالاسم الرومانسي
Labean (
hussars ، ابق هادئًا!).
بالنظر إلى: خادمنا ، الذي يعمل عليه Nginx على المنفذ 443 بشهادات مهيأة بشكل صحيح ويعرض بعض المحتوى غير الضار تمامًا ، على سبيل المثال ، ملفات GIF مع القطط ، صور ISO لتوزيعات GNU / Linux ، أو مرآة Wikipedia ومكتبة Moshkov.
في نفس الوقت ، اختبأت خطوط النموذج في تكوين Nginx
location ~ ^/somesecret/(.*) {
auth_basic "Administrator Login";
auth_basic_user_file /var/www/.htpasswd;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:8080/$1;
}
, CURL'
https://ourserver.org/somesecret/vpn/on
, , , IP-, -
iptables -t nat -A PREROUTING -p tcp -s {clientIP} --dport 443 -j REDIRECT --to-port 4443
.
N (, ) , , , IP .
, , URL , /off .
, IPv6 (v6- X-Real-IP ).
Go, , , . , nginx init- Gihub:
https://github.com/uprt/labeanWebsockets

: HTTPS — . Web- TCP , Websocket (
RFC 6455). HTTP-, , TCP-. , , HTTPS .
WS , - — , CDN, , Cloudflare . , : IP CDN/proxy CDN, VPN/proxy CDN, .
WS- ( Haskell),
wstunnel, nodejs , .
. wss://-,
wstunnel -t 33 wss://server:443
, «» ws- «» . wstunnel, , URI - :
wstunnel -t 33 wss://ourserver.org:443/hiddenws/
:
, 443 Nginx c - .
proxy- Websockets-:
location /hiddenws {
proxy_pass http://127.0.0.1:8081;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
websockets-. SOCKS- (, Dante), OpenVPN, , , .
selinuxRHEL , SELinux, nginx
2018/07/05 13:28:03 [crit] 7724#0: *11 connect() to 127.0.0.1:8081 failed (13: Permission denied) while connecting to upstream, client: IP_ADDRES, server: _, request: «GET /hiddenws/?dst=localhost:22 HTTP/1.1», upstream: «127.0.0.1:8081/hiddenws/?dst=localhost:22»,
:
semanage port -a -t http_port_t -p tcp 22
semanage port -m -t http_port_t -p tcp 22
semanage port -a -t http_port_t -p tcp 8081
Renatk .
— SOCKS- VPN- wstunnel, «» .
, v2ray shadowcocks, websockets shadowsocks. :
https://github.com/shadowsocks/v2ray-plugin— VPN- - MTU, 1400;
— VPN- 2 IP-. VPN/, ;
— «» IP- , ICMP ping;
— - reverse DNS , -, , gateway-001.somehomeisp.net;
— VPN/ DNS-
OpenNIC;
(
).

- , — . , , — , , . , HTTPS — , , - « »/ /etc., , « »,
.
, , , , — , , , .
.