Kita hidup di masa yang menarik. Saya bahkan akan mengatakan dengan cara yang luar biasa. Di satu sisi, kita melihat beberapa orang yang benar-benar ingin tahu apa yang orang lain bicarakan satu sama lain, dan benar-benar ingin memberi tahu mereka apa yang bisa dibaca dan yang tidak bisa dibaca. Di sisi lain, warga negara yang ingin menegaskan hak mereka atas rahasia korespondensi pribadi dan informasi gratis, dan tidak ingin fakta-fakta korespondensi ini dan penerimaan informasi ini digunakan untuk melawan mereka. Sejumlah besar situs pihak ketiga, layanan dan bisnis yang terkena "kunci karpet" menderita sebagai bonus.
Tapi tidak, artikel ini bukan tentang masyarakat, tetapi tentang teknologi.

Literasi teknis orang, berkat semua yang terjadi, juga berkembang. Jika sebelumnya kata-kata "VPN" dan "proksi" hanya akrab dengan spesialis IT, sekarang bahkan ibu rumah tangga mengenal mereka, dan terlebih lagi, mereka menggunakan apa arti kata-kata ini.
Secara umum, berita baru-baru ini datang cukup menghibur. Misalnya, penyediaan layanan VPN dan sejenisnya untuk mengenkripsi lalu lintas dan memotong kunci
sekarang dapat dihukum , dan di Cina mereka biasanya
memenjarakan mereka karena hal ini. Dan belum lama berselang, ILV mulai menggunakan
analisis paket untuk memblokir protokol MTProxy. Anda juga dapat merujuk pada pengalaman negara-negara sesama yang paling sukses dalam hal-hal seperti: Cina, Iran, Kazakhstan, Venezuela. Di Venezuela, misalnya, mereka secara langsung
memblokir koneksi langsung ke Tor dan mengacaukan lalu lintas ke jembatan. Berdasarkan semua ini, kita dapat mengasumsikan bahwa masa depan menanti kita juga sangat menarik, terutama jika "orang yang bertanggung jawab" berhenti membuat kepura-puraan bodoh berulang-ulang, dan bertindak lebih pintar dan lebih canggih.
Pada Habré berulang kali dalam komentar menyuarakan perkiraan tentang bagaimana perjuangan dengan teknologi enkripsi untuk warga biasa dapat berlanjut. Menganalisis pemikiran yang disuarakan dan melihat kesaksian dari negara lain, saya mencoba menyarankan ke arah mana langkah-langkah untuk membatasi komunikasi dapat bergerak lebih jauh.
DistortNeo dan
shifttstas memunculkan beberapa ide yang lebih menarik, dan pada akhirnya saya berjanji pada
el777 untuk menambahkan artikel ini.
Dengan filter ACL, semuanya jelas. Mereka bertindak sekarang, dan dengan berbagai keberhasilan mereka berhasil dan gagal untuk bertarung (walaupun ada
ramalan yang cukup
pesimistis ). DPI lebih menarik.
Metode "menentukan" jenis lalu lintas untuk DPI dapat dibagi menjadi dua kelompok:
- Analisis tanda tangan. Yaitu, membongkar paket "dengan tulang", membandingkan header dan struktur dengan sampel, dan dengan demikian menentukan tujuannya. Dengan demikian, banyak terowongan terdeteksi, misalnya, OpenVPN, L2TP / IPSec, SOCKS, dll.
- Analisis awal dari pola pertukaran lalu lintas, misalnya, rasio aliran masuk / keluar, frekuensi permintaan-respons dan kriteria lainnya akan memungkinkan kita untuk memisahkan "lalu lintas nyata" dari suatu protokol dan terowongan yang hanya menyamar sebagai protokol.

Anda dapat memecah lalu lintas menjadi beberapa grup dan menganggap apa yang akan mereka lakukan dengan masing-masing.
- VPN, terowongan, dan proksi "Eksplisit" (OpenVPN, L2TP / IPSec, SOCKS, dll.) VPN dan terowongan biasa mungkin diblokir secara otomatis, seperti, misalnya, ini terjadi di Cina dan Venezuela. Jika beberapa organisasi atau perusahaan membutuhkannya untuk bekerja, biarkan mereka mendaftar dan memberikan sertifikasi, seperti yang dibicarakan oleh hukum Rusia di atas. Dengan proxy, bahkan lebih mudah - HTTP itu, bahwa SOCKS mengirimkan alamat dan konten dalam teks yang jelas, yang umumnya tidak menciptakan masalah untuk “memotong” permintaan dan penyadapan informasi transmisi secara selektif.
- Teknologi penggunaan ganda seperti SSH . Beberapa saat setelah sesi ditetapkan, kecepatan dipotong menjadi kura-kura, sehingga Anda masih bisa bekerja setidaknya di konsol, tetapi tidak ada lagi selancar dan unduhan. Fakta bahwa ini menciptakan masalah selama kerja normal tidak mengganggu siapa pun (yang telah ditunjukkan kepada kami oleh ILV lebih dari sekali dalam beberapa kali terakhir).
- Protokol yang sangat spesifik, seperti messenger, klien game, dll.
- Senyawa yang tipenya tidak dapat ditentukan .
Untuk item 3 dan 4, "daftar putih" sangat mungkin (di mana, misalnya, subnet dari server game resmi atau utusan "yang benar" dimasukkan, dan semua yang ingin dinyatakan dan diatur oleh pemilik server sesuai kebutuhan sehingga tidak disentuh, dengan analogi dengan yang sudah dimiliki ILV untuk domain dan alamat IP). Dan mereka yang tidak ada dalam daftar ini akan menghadapi nasib yang sama seperti paragraf 1 atau paragraf 2, meskipun sangat mungkin untuk tidak secara blak-blakan memblokir atau memotong kecepatan, tetapi untuk menganalisis pola pertukaran yang disebutkan sebelumnya untuk menentukan apakah lalu lintas “murni” "Atau" curiga. "
Artinya, jika Anda ingin menyamarkan diri Anda sebagai protokol khusus, atau mengaburkan koneksi sehingga tidak mungkin untuk menentukan tipenya, Anda juga harus berhati-hati menciptakan "noise" yang mencegah deteksi pola pertukaran riil. Sejauh ini, perkembangan seperti itu belum sampai ke mata saya.
Anda bahkan tidak dapat mengingat tentang terowongan ICMP dan DNS yang berbeda - sejumlah besar lalu lintas "jika tidak diperlukan" secara otomatis juga menimbulkan kecurigaan.
5.
TLS dan SSL, HTTPS . Tidak mungkin untuk memotong bersih, karena ini secara otomatis berarti memblokir seluruh Internet. Analisis pola tidak masuk akal, karena berselancar di web hanyalah tujuan utama menggunakan HTTPS. Dari semua hal di atas, SSL / TLS pada port 443 sepertinya merupakan opsi yang paling “tidak curiga” dan dapat diandalkan. Karena itu, mari kita coba menyamarkan diri kita sebagai dia.

Menyamarkan diri kita sendiri
Untuk pertimbangan, diputuskan untuk memilih solusi Streisand dan SoftEther.
Streisand - seluruh rangkaian layanan berbeda: OpenConnect / AnyConnect, OpenVPN, stunnel, Shadowsocks, WireGuard. Semua ini diatur dalam mode "turnkey" otomatis atau semi-otomatis, dan pada output pengguna menerima server yang dikonfigurasi, serta file dan dokumentasi terperinci untuk mengatur klien.
SoftEther adalah server VPN yang dapat mengangkat L2TP / IPsec, OpenVPN, SSTP, dan protokol lainnya, dan juga memiliki protokol SSL-VPN sendiri, yang, menurut penulis, tidak dapat dibedakan dari lalu lintas HTTPS normal.
Jadi ...
OpenConnect / AnyConnect. Implementasi open source dari protokol SSL Cisco AnyConnect. Ketika koneksi dibuat, tidak hanya paket TLS (TCP), tetapi juga paket DTLS (UDP) terlihat. DTLS, pada prinsipnya, juga banyak digunakan di mana "untuk tujuan damai", tetapi ini sama sekali tidak seperti "HTTPS normal". Namun, jika Anda memotong lalu lintas UDP di firewall, AnyConnect segera beralih kembali ke TCP dan dari tampilan luar, sekali lagi, sepenuhnya dan sepenuhnya seperti TLS normal, dan bahkan otentikasi di dalam terowongan terenkripsi hampir seperti di HTTP.
Shadowsocks . Proksi SOCKS terenkripsi. Tampaknya, jika diinginkan,
dapat dideteksi , namun, ada plugin yang
menyamarkannya sebagai "HTTPS murni" . Ada juga
plugin untuk bekerja melalui soket web, tetapi lebih lanjut tentang itu nanti.
Wireguard Dilihat dari deskripsi, ini memiliki enkripsi yang sangat baik dan mekanisme pengaturan sesi, tetapi semua komunikasi terjadi melalui UDP. Wireshark mendefinisikan jenis paket sebagai sesuatu yang sama sekali tidak terdengar, dan apa pendapat tentang apa yang terjadi dengan DPI pihak ketiga adalah pertanyaan yang sangat, sangat besar.
Pembaruan: Versi yang lebih baru mendefinisikan Wireguard secara unik sebagai Wireguard, sehingga jawaban atas pertanyaannya jelas.
obfs3, obfs4 . Paket akan dikaburkan sehingga dari luar mereka terlihat seperti set nilai yang benar-benar acak. Artinya, mereka termasuk dalam item 4 dari daftar di atas.
SoftEther Sepertinya HTTPS, tetapi dengan satu tangkapan. Selain secara langsung TLS melalui TCP, secara aktif mengirimkan paket-paket paket UDP. Seperti yang ditemukan dalam dokumentasi, UDP dapat digunakan untuk mempercepat transfer data dalam kasus ketika tidak terbunuh di firewall. Fungsi ini dinonaktifkan dalam konfigurasi, dan setelah dinonaktifkan, semuanya menjadi sebagaimana mestinya.
SSTP . Prokotol VPN dari Microsoft. Didukung secara asli pada Windows, perangkat lunak pendukung pada GNU / Linux. Dari luar sepertinya HTTPS, dan Wireshark sepenuhnya mengkonfirmasi ini.
Tapi itu belum semuanya
Misalkan Anda menginstal server VPN atau ujung terowongan pada host dan mengkonfigurasinya untuk mendengarkan pada port 443. Tampaknya semuanya baik-baik saja, tetapi ada satu TETAPI: jika kami menyamarkan diri sebagai HTTPS, Anda dapat memverifikasi bahwa sebenarnya hang pada port 443 hanya dengan mencoba mengubur diri Anda di port ini dengan browser sederhana atau CURL, atau dengan cara lain. Dalam beberapa artikel, metode seperti ini disebut "koneksi utama", dan, sebagaimana disebutkan, sudah cukup digunakan di Cina.
Oleh karena itu, kita perlu bahwa pada port ke-443 kita memiliki server web yang paling biasa dan layak. Dan di sini muncul masalah yang menarik.
Tidak satu pun dari layanan di atas dalam dokumentasi utama yang menemukan deskripsi mekanisme kerja berbagi port.
Opsi SSLH tidak cocok, jika hanya karena sslh tidak dapat berbagi lalu lintas antara HTTPS dan layanan di atas. Paling tidak, karena jika jenis traffic tanpa dekripsi penuh bisa membedakan sslh, maka DPI akan bisa.
Sebagian besar orang, seperti
ini , menyarankan untuk menggunakan Server Name Indication (SNI) - ekstensi TLS yang memungkinkan Anda menentukan nama host, dan kemudian menggunakan HAProxy, sniproxy, dan alat lain untuk menyebarkan koneksi untuk layanan. Masalahnya adalah bahwa dalam implementasi TLS modern, nama host yang ditentukan ketika menggunakan SNI ditransmisikan dalam teks biasa, yaitu, dalam bentuk tidak terenkripsi, dan, karenanya, juga dapat dimata-matai dan digunakan di masa depan.
Karena itu, kami akan berimprovisasi, dan kemudian dua pilihan muncul di benak saya.
Mengetuk port

Port knocking hanya dirancang untuk mengaktifkan "layanan tersembunyi" di server. Misalnya, dengan cara yang serupa, port tempat daemon SSH hang sering ditutup "keluar" untuk menghindari kekerasan dan penggunaan kerentanan 0-hari. Dalam versi klasik (lihat, misalnya, penerapan daemon knockd), mengetuk biasanya dipahami sebagai upaya untuk membangun koneksi atau mengirim paket ke port host tertentu dalam urutan tertentu, sebagai akibatnya daemon “mengenali” Anda sebagai miliknya dan mengaktifkan aturan firewall yang memungkinkan akses ke port tertentu hanya dari IP Anda.
Dalam kasus kami, opsi ini tidak sepenuhnya dapat diterima. Pertama, port “non-standar” itu sendiri mungkin diblokir di suatu tempat di sepanjang jalan, dan kedua, prosedur itu sendiri, ketika dianalisis dari luar, mungkin terlihat mencurigakan. Karena kita menyamar sebagai HTTPS, kita perlu “mengetuk” HTTPS.
Anehnya, tidak ada pengetuk HTTP / HTTPS dengan fungsi yang diperlukan, dan karenanya seorang nocker dilahirkan dengan nama romantis
Labean (hussars, tetap diam!).
Diberikan: server kami, tempat Nginx beroperasi pada port 443 dengan sertifikat yang dikonfigurasi dengan benar dan menampilkan beberapa konten yang sama sekali tidak berbahaya, misalnya, GIF dengan kucing, gambar ISO dari distribusi GNU / Linux, atau cermin Wikipedia dan perpustakaan Moshkov.
Pada saat yang sama, garis-garis bentuk bersembunyi di konfigurasi 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., , « »,
.
, , , , — , , , .
.