Mengapa balasan UDP OpenVPN keluar dari alamat yang salah
Server UDP dengan beberapa alamat lokal dapat menjawab klien dari alamat yang berbeda dari yang dihubunginya. multihome memperbaiki sumber pada platform yang didukung.
Klien OpenVPN menghubungi satu alamat, server menjawab dari alamat lain, dan tunnel tidak pernah terangkat. Log server menunjukkan paket datang dan tangkapan menunjukkan balasan keluar, sehingga kegagalan dituduhkan ke klien. Pada host dengan beberapa antarmuka, atau beberapa alamat pada satu antarmuka, kedua sisi simpelnya tidak sepakat alamat mana yang dipakai. Balasan itu sah di lapisan IP, namun banyak klien membuang datagram yang sumbernya bukan alamat yang mereka hubungi.
Apa yang dilihat klien saat sumber berubah
Socket UDP yang tidak diikat ke alamat lokal tertentu tidak punya sumber tetap, jadi kernel memilih satu saat pengiriman. Pilihan itu berasal dari pencarian rute menuju alamat klien, dan sumbernya menjadi alamat antarmuka yang dipilih pencarian tersebut. Pada mesin dengan satu antarmuka pilihan itu tak terlihat; pada host dengan alamat manajemen, alamat publik, dan alamat sekunder pada kartu jaringan yang sama, pilihan itu bergantung pada metrik dan kebijakan perutean. Perutean berbasis kebijakan membuat ketidakcocokan lebih mungkin, bukan lebih kecil, karena aturan dapat memilih uplink yang tidak pernah dicapai klien. Rute default yang dipelajari dari satu penyedia plus aturan sumber yang menunjuk ke penyedia lain sudah cukup untuk menghasilkannya.
Klien yang memfilter balasan, dan pelacakan koneksi yang mengharapkan kuadruplet persis serta sumbernya, akan membuang balasan itu tanpa pesan yang berguna. Tunnel lalu habis waktu seolah tidak ada yang datang, dan itulah sebabnya ini keliru dianggap masalah firewall di sisi klien. Tangkapan yang diambil hanya di server menegaskan kesalahan itu alih-alih menjelaskannya, karena balasan memang benar-benar keluar. Bandingkan sumber balasan dengan alamat yang dihubungi klien sebelum mengubah apa pun yang lain.
Apa yang sebenarnya dilakukan opsi multihome
Direktif ditulis multihome dalam berkas konfigurasi dan --multihome pada baris perintah, dan itu membuat server UDP menjawab dari alamat yang dicapai paket klien. Kernel menyerahkan alamat tujuan asli sebagai data tambahan saat menerima, dan OpenVPN memakai nilai itu sebagai sumber balasan. Dengan begitu server yang mendengarkan pada alamat wildcard, local 0.0.0.0 untuk IPv4 atau padanan IPv6-nya, berperilaku seolah setiap klien mencapai pendengar khusus. Klien yang masuk melalui alamat publik mendapat balasan dari alamat publik, dan klien pada alamat internal mendapat balasan dari alamat itu. Tidak ada hal lain di jalur paket yang bergerak: rute, aturan filter, dan konfigurasi tunnel tetap persis seperti sebelumnya.
Sifat terakhir itulah yang membuat opsi ini aman ditambahkan ke server yang sudah berjalan, dan juga sebabnya opsi ini tidak dapat memperbaiki filter yang hanya mengizinkan satu alamat. Paket tetap harus diterima pada jalur yang dilaluinya, jadi koreksi sumber mengubah asal balasan dan tidak lebih. Opsi ini juga hanya untuk UDP: pendengar TCP tidak mengalami masalah ini dalam bentuk yang sama, karena koneksi diidentifikasi oleh kuadruplet, bukan oleh alamat sumber balasan.
Kapan alamat lokal tetap adalah default yang salah
Sebelum memakai opsi itu, periksa apakah server mengikat satu alamat lokal tertentu, karena pendengar yang terikat selalu menjawab dari alamat tersebut. Itu benar untuk penerapan satu antarmuka dan salah begitu klien secara sah memakai lebih dari satu alamat. Jika pengikatan itu disengaja, putuskan apakah server memang harus menerima lalu lintas pada alamat tambahan. Melepas pengikatan menambah paparan, jadi antarmuka dan jaringan sumber yang diizinkan harus ditegakkan oleh layanan dan filter, bukan hanya oleh alamat pengikatan.
Referensi OpenVPN membatasi opsi ini pada server UDP, mencatat pemrosesan tambahan di jalur paket, dan mencatat platform mana yang mendukungnya. Pastikan hal itu pada rilis yang terpasang sebelum merencanakan berdasarkan itu. Di tempat yang tidak didukung, mengikat alamat tertentu atau memperbaiki rute balik adalah alternatifnya, dan keduanya perubahan yang lebih sempit daripada yang tampak pada pandangan pertama. Mendengarkan pada wildcard juga punya akibat di luar balasan: server pada semua alamat dapat dijangkau dari setiap jaringan tempat host terpasang, dan itu mungkin bukan paparan yang dimaksud siapa pun.
Buktikan sumber balasan dari luar
Uji dari luar server, dan catat alamat serta transport persis yang dipakai klien sebelum menangkap apa pun. Tiga pemeriksaan di bawah menjawab tiga pertanyaan berbeda, dan urutannya penting.
tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20
Tangkapan menunjukkan alamat sumber pada balasan, dan itulah fakta yang menjadi dasar seluruh artikel. Daftar socket menunjukkan apa yang benar-benar diikat server, karena pendengar wildcard dan pendengar tertentu terlihat identik dalam berkas konfigurasi dan berperilaku berbeda di jaringan. Pencarian rute menunjukkan sumber yang akan dipilih kernel untuk aliran itu, dan itu menjelaskan tangkapan sebelum Anda mengubah apa pun. Ulangi ketiganya untuk IPv4 dan IPv6 secara terpisah, karena keduanya pendengar terpisah dan pencarian terpisah, dan entri wildcard untuk satu keluarga tidak mengatakan apa pun tentang yang lain.
Perutean, penemuan, dan pemfilteran tetap terpisah
Mempertahankan sumber balasan tidak memasang rute keluar, tidak memperbarui DNS dinamis, dan tidak membuat satu keluarga alamat menerima keluarga lain. Pada server dengan beberapa uplink, jalur balik untuk setiap sumber harus disepakati dengan sengaja, atau balasan keluar melalui antarmuka yang tidak pernah diizinkan filter klien. Demikian pula, alamat baru setelah perubahan prefiks harus sampai ke klien melalui penemuan dan alur sambung ulang yang didukung, bukan melalui catatan lama.
Biarkan pemeriksaan identitas server dan verifikasi sertifikat persis seperti adanya, karena alamat yang berubah tidak membenarkan menerima rekan yang belum diverifikasi. Jika balasan sekarang keluar dari sumber yang dimaksud dan tunnel tetap gagal, anggap masalah sumber selesai dan lanjutkan. Kesalahan berikutnya yang teramati milik perutean, pemfilteran, atau autentikasi, dan mengubah pendengar lagi tidak akan mencapainya. Tuliskan sumber balasan di tiket di samping alamat yang dihubungi klien, agar orang berikutnya dapat memeriksa fakta yang sama dengan satu perintah.