tunneler

terowongan

Repo ini berisi klien dan server yang memungkinkan Anda melakukan terowongan lalu lintas TCP dan UDP melalui protokol jaringan lain.

Saat ini, terowongan yang didukung adalah:

• DNS (server otoritatif atau koneksi langsung)
• TLS (otentikasi timbal balik)
• TCP

Alat utama ditulis dalam Rust dan pengujian ujung ke ujung ditulis dengan Python.

Instalasi

Opsi 1: gambar buruh pelabuhan klien dan server

docker pull ghcr.io/dlemel8/tunneler-server:latest
docker pull ghcr.io/dlemel8/tunneler-client:latest

Opsi 2: kompilasi dari kode sumber

cargo --version || curl --proto ' =https ' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo build --release

Ada juga file buruh pelabuhan jika Anda lebih suka membuat image buruh pelabuhan lokal

Penggunaan

Opsi 1: gambar buruh pelabuhan klien dan server

docker run -e LOCAL_PORT=45301 
           -e REMOTE_PORT=5201 
           -e REMOTE_ADDRESS=localhost 
           -e TUNNELED_TYPE=udp 
           --rm -p 45301:45301 ghcr.io/dlemel8/tunneler-server:latest tcp

Opsi 2: biner yang dikompilasi secara lokal

./target/release/client 
  --tunneled-type tcp 
  --remote-address 1.1.1.1 
  --remote-port 53 
  --log-level debug 
  dns 
  --read-timeout-in-milliseconds 100 
  --idle-client-timeout-in-milliseconds 30000

Jalankan gambar buruh pelabuhan atau biner terkompilasi dengan --help untuk informasi lebih lanjut

Pengujian

Jalankan Tes Unit

cargo test --all-targets

Jalankan Tes End-to-End

python3 -m pip install -r e2e_tests/requirements.txt
PYTHONPATH=. python3 -m pytest -v

Contoh

Repo ini berisi beberapa contoh penerapan server menggunakan Docker Compose:

• Tes Kecepatan - server iperf3 diekspos melalui semua terowongan yang didukung, memungkinkan Anda membandingkan kecepatan terowongan.
• DNS Otoritatif - Server Redis terekspos melalui terowongan DNS pada port UDP/53. Karena terowongan tidak memverifikasi klien, autentikasi Redis diperlukan.
• Pipeline - Server Redis diekspos melalui terowongan TLS yang diekspos sendiri melalui terowongan DNS. Karena terowongan memverifikasi klien, autentikasi Redis tidak digunakan.

Anda dapat menjalankan setiap contoh secara lokal atau menerapkannya menggunakan Terraform dan Ansible. Lihat informasi lebih lanjut di sini.

Arsitektur

Setiap executable berisi 2 komponen yang berkomunikasi melalui saluran aliran klien (tupel pembaca dan penulis byte):

• Pendengar Klien mengikat soket dan mengubah lalu lintas masuk dan keluar ke aliran baru.
• Tunneler Klien menerjemahkan pembaca dan penulis aliran ke protokol terowongan.
• Server Untunneler mengikat soket sesuai dengan protokol terowongan dan menerjemahkan lalu lintas yang disalurkan kembali ke aliran asli.
• Server Forwarder mengubah penulis dan pembaca aliran kembali menjadi lalu lintas.

Lalu lintas berbasis TCP dengan mudah diubah menjadi aliran. Konversi lalu lintas berbasis UDP bergantung pada protokol terowongan.

Lalu lintas berbasis UDP juga memerlukan cara untuk mengidentifikasi klien yang ada untuk melanjutkan sesi mereka. Solusinya adalah Cache Klien dalam memori yang memetakan pengidentifikasi klien ke alirannya.

Protokol

UDP yang disalurkan

Untuk mengubah lalu lintas UDP menjadi aliran, header berukuran 2 byte (dalam big endian) mendahului setiap muatan paket.

UDP Listener menggunakan alamat rekan paket yang masuk sebagai kunci untuk Cache Kliennya.

Penerowongan DNS

Kami memiliki beberapa tantangan di sini:

• Payload DNS harus alfanumerik.
• Setiap pesan memerlukan respons sebelum kami dapat mengirim pesan berikutnya.
• Setiap kueri DNS menggunakan port sumber dan ID transaksi yang diacak, jadi kami tidak dapat menggunakannya sebagai kunci Cache Klien.

Untuk mengatasi tantangan tersebut, setiap sesi klien dimulai dengan menghasilkan ID Klien acak (4 karakter alfanumerik). Klien membaca data ke terowongan dan menjalankannya melalui saluran pembuat enkode:

• Data dikodekan dalam hex.
• ID Klien ditambahkan.
• Akhiran klien ditambahkan. Jika server berjalan di server DNS otoritatif Anda, akhirannya adalah ".<domain Anda>".

Data yang dikodekan kemudian digunakan sebagai nama kueri DNS TXT.

Jika Anda memiliki server DNS otoritatif, klien dapat mengirimkan permintaan ke penyelesai DNS rekursif. Resolver akan mendapatkan IP Anda dari pencatat nama domain Anda dan meneruskan permintaan ke IP Anda. Opsi lain (lebih cepat tetapi lebih jelas bagi penganalisis lalu lintas mana pun) adalah mengonfigurasi klien untuk mengirim permintaan langsung ke IP Anda (pada port UDP/53 atau server port lain yang mendengarkan).

Server menerjemahkan data (mengabaikan lalu lintas non-klien) dan menggunakan ID Klien sebagai kunci untuk Cache Kliennya.

Untuk menangani respons server yang besar dan ACK TCP yang kosong, batas waktu baca digunakan di klien dan server. Jika batas waktu baca habis, pesan kosong akan dikirim. Baik klien maupun server menggunakan waktu tunggu diam untuk menghentikan penerusan dan membersihkan sumber daya lokal.

Terowongan TLS

Untuk menerapkan autentikasi timbal balik, kami menggunakan Otoritas Sertifikat privat:

• Sertifikat CA yang ditandatangani sendiri dihasilkan dari kunci pribadi.
• Kunci pribadi server dibuat secara acak dan bagian publiknya digunakan dalam sertifikat yang ditandatangani oleh sertifikat CA.
• Kunci pribadi klien dibuat secara acak dan bagian publiknya digunakan dalam sertifikat yang ditandatangani oleh sertifikat CA.

Klien dan server dikonfigurasi untuk menggunakan kunci dan sertifikatnya dalam jabat tangan TLS. Sertifikat CA digunakan sebagai sertifikat root.

Karena ekstensi Indikasi Nama Server digunakan, klien meminta nama server tertentu dan server menyajikan sertifikatnya hanya jika nama itu diminta. Nama server juga harus menjadi bagian dari sertifikat, misalnya sebagai Nama Alternatif Subjek.