MULTI: alamat sumber salah dari klien: alamat siapa itu?
Sumber internal tidak cocok dengan klien yang mengantarkannya. Cocokkan dengan penetapan tunnel, LAN di belakang klien, atau identitas ganda.
Log server mencetak MULTI: bad source address from client, membuang paket, dan sesi tetap terhubung. Kombinasi itu membingungkan orang yang membaca pesan sebagai kegagalan autentikasi. Bukan begitu: klien sudah terautentikasi, dan paket yang tiba membawa alamat sumber internal yang tidak dapat dikaitkan server dengan instans klien tersebut. Pemeriksaan terjadi sebelum pengiriman, karena itu tunnel tampak sehat sementara tidak ada yang berguna melintasinya.
Apa yang dibandingkan server sebelum pengiriman
Untuk setiap paket yang datang dari klien, server di ruang pengguna melihat alamat sumber di dalam tunnel dan menanyakan keadaan routing internalnya klien mana pemilik alamat itu. Jika pemiliknya instans lain, atau tidak ada pemilik sama sekali, paket dibuang dan peringatan dikeluarkan.
Pengiriman biasa melalui antarmuka tunnel tidak pernah terjadi.
Urutan itu menjelaskan detail yang membingungkan orang: penghitung firewall host tidak bergerak, karena paket tidak pernah mencapai firewall. Menyesuaikan penyaringan jalur balik pada host tidak mengubah apa pun di sini, karena penolakan terjadi dalam pemeriksaan asosiasi milik daemon itu sendiri. Baca pesan itu sebagai pernyataan tentang kepemilikan, lalu cari tahu mana dari tiga situasi yang menghasilkannya.
Tiga sumber alamat internal yang tidak cocok
Klien mungkin mengirim dari alamat yang tidak ditetapkan untuknya, dari jaringan yang tidak dinyatakan siapa pun sebagai miliknya, atau dari duplikat identitas yang sudah punya pemilik. Ketiganya menghasilkan baris log yang sama. Mereka berbeda dalam apa yang harus Anda ubah. Mulailah dari alamat dan daftar penetapan saat ini, dan biarkan kedua fakta itu memilih kasusnya.
Membedakannya memerlukan dua fakta: alamat yang ditolak di log, dan penetapan yang dianggap server sebagai yang berlaku. Yang kedua tersedia dari tampilan status atau manajemen instans yang berjalan, dan itulah satu-satunya otoritas yang layak dikonsultasikan, karena berkas konfigurasi mencatat niat, bukan keadaan saat ini.
Catat keduanya sebelum mengubah apa pun, lalu klasifikasikan. Tangkapan layar yang diambil sesudahnya bukan catatan keadaan yang menghasilkan peringatan itu. Simpan juga stempel waktunya, karena penetapan berpindah antar sesi.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
LAN di belakang klien dan iroute
Ketika klien situs merutekan jaringan pribadinya sendiri, jaringan itu harus dinyatakan sebagai milik klien. Berkas khusus klien dengan entri iroute melakukannya, dan entri itu menyebut prefiks yang boleh dibawa klien.
Rute kernel yang mengarahkan prefiks yang sama ke tunnel adalah persyaratan terpisah, dan menambahkannya tidak mengubah apa pun pada kepemilikan internal daemon.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Pastikan identitas efektif cocok dengan nama berkas, karena ketidakcocokan berarti berkas tidak pernah dimuat dan gejalanya identik dengan entri yang hilang. Jangan menambahkan iroute lebar untuk membungkam peringatan, karena itu mengubah sumber tak terduga menjadi sumber yang diizinkan tanpa menjawab mengapa klien mengirimnya. Manual OpenVPN 2.6 mendokumentasikan iroute, duplicate-cn, dan pemetaan identitas sebagai kendali terpisah.
Identitas yang sama pada dua mesin
Profil yang disalin ke laptop kedua membawa sertifikat yang sama dan nama umum yang sama. Bergantung pada pengaturan server, koneksi yang lebih baru dapat menggantikan yang lebih lama, dan instans mana pun yang memegang kepemilikan memenangkan pemeriksaan asosiasi.
Itu membuat gangguan tampak berkala dan hanya muncul saat kedua perangkat terjaga.
Mengizinkan nama umum ganda membuat keduanya dapat terhubung, tetapi tidak memberi mereka alamat statis independen atau kepemilikan independen. Jika dua perangkat harus hidup berdampingan, daftarkan keduanya secara terpisah agar masing-masing punya identitas dan penetapannya sendiri. Memperlakukan pengaturan duplikat sebagai perbaikan untuk peringatan ini membiarkan misterinya tetap ada dan menambahkan yang kedua.
Buktikan asosiasinya berubah
Terapkan koreksinya melalui pemilik konfigurasi, lalu sambungkan ulang klien yang terdampak agar kebijakan baru dimuat.
Ulangi alur yang sama dan pastikan tiga hal: sumber internal paket, instans klien yang dikaitkan server dengannya, dan perilaku tujuan sesudahnya.
Jika peringatan berhenti tetapi aplikasi masih gagal, masalahnya berpindah, bukan hilang. Penerusan, aturan firewall, dan jalur balik adalah tahap terpisah, dan lulus pemeriksaan asosiasi hanya berarti paket diizinkan meninggalkan tunnel.