OpenVPN TAP di macOS: periksa klien sebelum melakukan debug
TAP membawa frame Ethernet dan TUN membawa IP, dan sebagian besar klien macOS saat ini sudah meninggalkan yang pertama. Pastikan modenya, lalu bermigrasi bersama pemilik server.
Profil lama mendarat di Mac modern, klien mengimpornya tanpa keluhan, dan koneksi terputus atau tidak pernah melewatkan trafik. Sebelum menghabiskan satu sore untuk sertifikat, bacalah baris perangkat di profil. Jika tertulis dev tap, Anda meminta klien menyediakan antarmuka bergaya Ethernet, dan di macOS justru permintaan itulah yang mengakhiri sebagian besar sesi semacam ini.
Langkah 1: pastikan profil benar-benar meminta TAP
Profil diganti nama, dibungkus, dan diekspor ulang, jadi periksa berkas yang benar-benar Anda impor. Cari direktif perangkat dan setiap include yang mungkin menimpanya. Dua baris keluaran menyelesaikan pertanyaan pada sebagian besar kasus. Ketika dev dan dev-type muncul bersamaan, direktif yang lebih akhir menang, dan justru detail seperti itulah yang disembunyikan profil hasil salinan.
grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null
Jika berkas berisi dev tap atau dev tap0, klien harus menerapkan antarmuka TAP. Jika berisi dev tun, sisa artikel ini tidak berlaku dan kegagalannya ada di tempat lain.
Catat nama dan versi klien, versi macOS, dan dari mana profil itu berasal. Ketiga fakta itu menentukan jalur mana dari dua jalur di bawah yang mungkin sama sekali.
Langkah 2: pahami apa yang sebenarnya diubah mode perangkat
Antarmuka TUN membawa paket IP. Klien membaca dan menulis paket yang dialamatkan ke rekan IP, dan sistem operasi merutekannya seperti antarmuka lain.
Antarmuka TAP membawa frame Ethernet, termasuk siaran dan ARP. Itulah yang memungkinkan server berjembatan membagikan alamat melalui DHCP dan klien menemukan perangkat dengan berseru, dan karena itu beberapa rancangan lama bergantung padanya.
Harganya adalah TAP memerlukan pengandar yang menyajikan antarmuka Ethernet kepada sistem. Apple telah menghentikan model ekstensi kernel yang menjadi sandaran pengandar TAP Mac lama, dan API penggantinya tidak muncul secara ajaib di dalam klien yang tidak pernah diperbarui untuk memakainya. Kemampuan platform dan produk yang sudah dikirim adalah dua hal berbeda.
Langkah 3: pilih antara klien yang kompatibel dan migrasi
Ada dua jalur jujur. Yang pertama adalah klien yang penerbitnya menyatakan, untuk rilis macOS dan perangkat keras Anda, bahwa klien itu mendukung susunan TAP yang Anda perlukan. Bukan kiriman forum dari empat tahun lalu, dan bukan pemasang yang diarsipkan: pernyataan terkini ditambah koneksi uji.
Yang kedua adalah memindahkan layanan ke TUN, yang sama-sama perubahan server dan perubahan klien. Ini membutuhkan topologi terutekan, kumpulan alamat, rute yang didorong untuk jaringan jarak jauh, dan jalur balik dari jaringan itu ke kumpulan alamat.
Yang tidak berhasil adalah mengubah tap menjadi tun di salinan lokal Anda lalu berharap. Server masih menjembatani, klien sekarang berbicara IP, dan tidak ada yang sepakat.
Langkah 4: kumpulkan fakta sebelum mengubah layanan yang berjalan
Biarkan profil asli tak tersentuh dan buat salinan untuk percobaan. Berkas yang dapat Anda pulihkan dalam satu menit lebih berharga daripada folder yang rapi. Setelah pengganti berfungsi, hapus salinan itu dengan sengaja daripada meninggalkan dua profil yang tampak sama di daftar. Satu kebiasaan itu mencegah sebagian besar kebingungan setelah migrasi yang gagal. Catat perilaku saat ini agar Anda dapat membuktikan apa yang berubah: apakah terowongan naik, apakah mendapat alamat, apakah Anda dapat menjangkau satu host yang dikenal, dan apakah resolusi nama berfungsi.
Tanyakan tiga hal kepada pemilik gerbang. Apakah server berjalan dengan topologi berjembatan atau terutekan? Prefiks jarak jauh mana yang seharusnya dapat dijangkau? Dan apakah ada jendela pemeliharaan untuk perubahan konfigurasi, atau apakah ini diharapkan berfungsi tanpa menyentuh server?
Jawaban atas itu menentukan apakah Anda menyelesaikan masalah klien sore ini atau merencanakan perubahan jaringan pekan depan.
Langkah 5: verifikasi migrasi dari kedua ujung
Setelah server memiliki konfigurasi terutekan dan Anda memiliki profil yang cocok, ujilah dalam urutan ini: terowongan terbentuk, klien menerima alamat dari kumpulan baru, host di sisi jauh menjawab, dan nama teresolusi melalui pengaturan DNS yang didorong.
Lalu uji apa yang dahulu bergantung pada perilaku Ethernet. Jika aplikasi menemukan perangkat melalui siaran, aplikasi itu tidak akan menemukannya melalui terowongan terutekan, dan tidak ada konfigurasi klien yang mengembalikannya. Aplikasi itu memerlukan alamat yang dikenal, host pembantu lokal, atau metode penemuan yang berbeda.
Akhiri dengan menyambung ulang dan memulai ulang sekali, karena profil yang hanya berfungsi pada percobaan pertama biasanya berarti rute yang didorong atau pengaturan DNS tidak diterapkan saat menyambung ulang.
Jika masih gagal, bacalah kesalahan pertama
Klien yang tidak dapat membuat antarmuka mengatakannya di log, biasanya pada beberapa baris pertama. Klien yang membuatnya lalu gagal mengautentikasi sudah jauh melewati pertanyaan perangkat, dan terus mengejar TAP hanya membuang sesi.
Simpan profil asli dan konfigurasi yang berfungsi sampai pengganti terbukti. Mengembalikan perubahan klien cepat; membangun ulang jaringan berjembatan yang dibongkar seseorang berdasarkan dugaan tidak cepat.