Mengapa wildcard dalam direktif route OpenVPN tidak bisa bekerja

Niatnya masuk akal: kirim semua untuk satu domain perusahaan melalui terowongan dan biarkan sisanya. Direktif yang sedang diedit memasang rute, dan rute tidak punya konsep nama host untuk dicocokkan. Setiap upaya menulis wildcard ke dalamnya menghasilkan entah galat penguraian atau, lebih buruk, rute yang hari ini kebetulan bekerja karena nama itu terselesaikan ke satu alamat. Dua mekanisme berbeda diminta melakukan pekerjaan satu sama lain.

Apa yang dipasang rute, dan apa yang tidak pernah dibacanya

Entri rute menyatakan bahwa sebuah prefiks tujuan dapat dicapai melalui antarmuka. Kernel mencocokkan paket dengan prefiks tersebut, jadi satu-satunya pengenal yang terlibat adalah alamat dan masker. Nama host tidak pernah muncul dalam keputusan penerusan, dan itulah sebabnya pola tidak dapat dicocokkan di sana.

OpenVPN dapat menerima nama yang dapat diselesaikan pada beberapa parameter rute, dan toleransi itu menjadi sumber kebingungan. Nama diselesaikan saat konfigurasi diterapkan, menghasilkan satu atau beberapa alamat yang menjadi rute biasa. Setelah itu, nama itu hilang sepenuhnya dari gambaran.

Jadi rute yang dibangun dari nama adalah cuplikan, bukan aturan. Ia mencakup apa pun yang menjadi tujuan nama itu pada saat terowongan dimulai, dan itulah tepatnya perilaku yang tidak Anda inginkan untuk keluarga host yang berubah. Catatan yang berpindah besok meninggalkan rute yang menunjuk ke kemarin.

Ketika tujuan benar-benar sebuah prefiks

Jika target adalah jaringan privat yang dikenal, tuliskan prefiksnya. Untuk contoh dari ruang dokumentasi, satu host dan satu subnet terlihat seperti ini:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Kedua entri menyebut alamat dan masker, dan keduanya bertahan terhadap perubahan DNS karena tidak ada yang bergantung pada nama. Itulah seluruh keuntungannya: rute adalah pernyataan tentang topologi, bukan tentang pencarian yang terjadi sekali.

Jangan menyimpulkan prefiks besar dari satu jawaban DNS. Satu nama host yang terselesaikan ke satu alamat tidak memberi tahu Anda apa pun tentang ukuran jaringan di belakangnya, dan prefiks yang ditebak adalah cara terowongan akhirnya menangkap lalu lintas yang tidak ingin dikirim siapa pun melaluinya. Tanyakan prefiks sebenarnya kepada pemilik jaringan alih-alih menyimpulkannya dari pencarian.

Ketika satuan kerjanya adalah nama host

Memilih berdasarkan domain memerlukan sesuatu yang membaca domain, yaitu komponen lapisan aplikasi. Jawaban yang biasa adalah proxy HTTP yang berada di sisi jauh terowongan, dengan klien memilih permintaan mana yang dikirim kepadanya.

Berkas konfigurasi proxy dapat menyatakan pilihan itu. Aturan ilustratif di bawah mengirim satu domain dan subdomainnya ke proxy dan segala hal lain secara langsung:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Perbandingan nama persis mencakup domain itu sendiri, dan perbandingan sufiks mencakup anak-anaknya tanpa mencocokkan nama yang sekadar berakhir dengan karakter serupa. Keduanya diperlukan, dan menghilangkan salah satunya menghasilkan aturan yang tampak benar dan melewati puncak atau penyusup.

Aturan ini memilih proxy; aturan tidak membuatnya, dan tidak mengubah rute sistem operasi mana pun. Alamat proxy tetap memerlukan jalurnya sendiri melalui terowongan, dan permintaan yang ditandai langsung tetap mengikuti kebijakan perutean yang sudah dimiliki mesin.

Apa yang tidak dicakup opsi proxy

Program yang mengabaikan konfigurasi proxy peramban tidak akan terpengaruh oleh semua ini. Alat baris perintah, pembaru, dan aplikasi dengan tumpukan jaringannya sendiri mengambil tabel rute, bukan berkas PAC, jadi kasus itu memerlukan mekanisme per aplikasi yang didukung atau desain lain. Inventarisasikan klien yang penting sebelum menjanjikan bahwa aturan peramban mencakup alur kerja.

Kembali langsung juga bukan jalan keluar. Jika kebijakan perutean mesin sudah mengirim semuanya ke terowongan, permintaan yang ditandai langsung tetap berada di dalamnya, karena pilihan proxy dan tabel rute adalah keputusan berbeda yang dibuat pada lapisan berbeda.

Resolusi nama adalah pertanyaan ketiga yang terpisah. Memilih permintaan mana yang pergi ke proxy tidak mengatakan apa pun tentang penyelesai mana yang menjawabnya, dan memperlakukan keduanya sebagai satu pengaturan menghasilkan kebocoran yang tak terlihat sampai seseorang menguji dari luar. Putuskan di mana setiap kueri dijawab dan tuliskan keputusan itu di samping aturan proxy. Penyelesai yang berubah karena terowongan naik akan memindahkan jawaban itu dengan diam-diam.

Menguji kedua jalur, bukan hanya yang mulus

Uji nama host yang seharusnya cocok, nama host yang seharusnya tidak, dan puncak domain, karena puncak adalah kasus yang paling sering terlewat oleh aturan hanya sufiks. Lalu pastikan jalur mana yang benar-benar diambil setiap permintaan alih-alih menyimpulkannya dari apakah halaman termuat.

Terakhir, uji cabang kegagalan. Proxy yang tidak dapat dijangkau harus gagal dengan cara yang telah Anda putuskan sebelumnya, bukan diam-diam kembali ke koneksi langsung. Referensi opsi jaringan mendokumentasikan parameter rute secara tepat; separuh domain dari desain ini hidup sepenuhnya di luarnya.