Dante SOCKS di loopback untuk Layanan HTTPS Khusus WireGuard

Runbook ini memberi aplikasi yang sadar-proxy akses ke jalur WireGuard yang sudah ada tanpa menerbitkan port proxy di server VPN atau internet. Daemon SOCKS menyediakan antarmuka aplikasi, WireGuard menyediakan jalur IP yang sudah disetujui, dan keduanya tidak mengautentikasi pengguna untuk Anda. Setiap langkah di bawah menghasilkan sesuatu yang dapat Anda periksa, dan masing-masing punya rollback: hentikan instans, hapus aturan, atau hapus pengaturan proxy aplikasi. Tidak ada yang mengubah rute default host.

Contoh mengasumsikan Dante 1.4.x dipasang sebagai instans khusus yang dikelola di workstation Linux tepercaya, dengan akun layanan dan konfigurasi logging dari paket dibiarkan di tempatnya. Workstation memiliki 10.77.0.2 pada antarmuka WireGuard-nya, menjangkau 10.60.0.20:443 melalui tunnel itu, dan nama resmi layanannya adalah app.corp.example.

Langkah 1: ikat pendengar hanya ke loopback

Letakkan bagian jaringan, metode, dan aturan ke konfigurasi aktif instans, menggantikan alamat contoh. Semua pengaturan server berada sebelum blok aturan:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

Ini adalah fragmen, bukan pengganti pengaturan pengguna dan logging dari paket. Pilih port lokal yang tidak terpakai, dan pastikan instans khusus ini tidak memiliki pendengar lain, aturan lolos yang lebih luas, dan entri rantai hulu yang akan mengubah kontrak. Jika konfigurasi sebelumnya meninggalkan socks pass tanpa batasan tujuan, hapus sebelum menguji apa pun.

Rollback untuk langkah ini adalah menghentikan instans; berkas konfigurasi dapat tetap di disk selama Anda mengembalikannya.

Langkah 2: tulis dua aturan, bukan satu

Referensi konfigurasi Dante memberi kedua jenis aturan tugas berbeda. Aturan klien mengizinkan koneksi ke pendengar loopback, dan tujuannya adalah alamat pendengar itu sendiri. Aturan SOCKS mengizinkan koneksi lanjutan yang diminta ke host dan port yang disetujui. Permintaan yang tidak cocok diblokir secara default, itulah sebabnya aturan yang hilang tampak identik dengan rute yang rusak.

Perhatikan apa yang sengaja tidak dilakukan konfigurasi ini: ia tidak meminta kata sandi SOCKS. Itu cocok untuk host lokal tepercaya, dan itu bukan autentikasi pengguna. Proses lain di mesin itu juga dapat memakai loopback. Pertahankan autentikasi aplikasi jarak jauh sendiri, dan jangan gunakan ulang bentuk tanpa autentikasi ini untuk pengguna lokal tidak tepercaya atau pendengar yang menghadap LAN.

Langkah 3: verifikasi rute dari sumber yang tepat

external memilih alamat sumber keluar; ia tidak memasang rute WireGuard. Pencarian hanya-baca untuk sumber dan tujuan contoh:

ip -4 route get 10.60.0.20 from 10.77.0.2

Jalankan itu di namespace jaringan Dante yang sebenarnya, bukan di shell apa pun yang kebetulan terbuka. Rute, pemilihan peer WireGuard, izin di sisi jarak jauh, dan jalur kembali semuanya harus cocok dengan alamat sumber itu. Pencarian yang berhasil itu perlu dan tidak cukup, karena tidak mengatakan apa pun tentang apakah ujung jauh menerima permintaan.

Tahan godaan untuk menambahkan rute default agar pencarian berhasil. Port proxy hanya ada di workstation ini; mengubah rute default host untuk membuatnya membalik seluruh rancangan.

Langkah 4: uji dengan identitas yang dimaksud

Setelah pemilik memvalidasi konfigurasi terpasang dan memulai instans melalui manajer layanannya, permintaan ilustratif adalah:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

Dengan socks5h, Dante melakukan resolusi tujuan, tetapi Dante berjalan di workstation ini, jadi pengaturan itu tidak mengirim DNS ke ujung jauh tunnel dengan sendirinya. Resolver yang disetujui yang dipakai Dante harus mengembalikan alamat yang diizinkan untuk nama itu. Daftar tanpa-proxy yang kosong mencegah pengecualian warisan diam-diam melewati SOCKS.

Pertahankan validasi nama host dan sertifikat HTTPS dalam uji, lalu periksa pendengar sebenarnya dan konfirmasi kedua bagian kontrak: permintaan yang diizinkan berhasil dan tujuan yang dikecualikan gagal. Verifikasi juga bahwa perintah penerusan yang tidak didukung tetap ditolak, karena fragmen ini mengizinkan perintah SOCKS CONNECT melalui TCP dan tidak ada yang menyerupai tunnel UDP umum atau seluruh perangkat.

Langkah 5: putuskan apa yang terjadi saat tunnel putus

Uji kehilangan tunnel dan mulai ulang instans sebelum Anda menyebutnya produksi. Supervisor yang memulai Dante setelah WireGuard tidak menciptakan perutean fail-closed, dan juga tidak menciptakan DNS fail-closed; keduanya harus ditegakkan melalui pemilik jaringan. Amati apa yang dilakukan aplikasi saat tunnel mati: kesalahan bersih adalah hasil baik, penurunan diam-diam ke resolver publik bukan.

Koordinasikan pembaruan jika alamat tunnel yang terikat berubah, karena external dipatok padanya. Saat pengaturan ini tidak lagi diperlukan, pensiunkan instans ini dan pengaturan proxy aplikasi bersama-sama, dan serahkan jalur WireGuard kepada siapa pun yang memilikinya.