Dua Pemilik, Satu Alamat: IP Duplikat di Jembatan TAP

Satu klien Windows memegang 10.8.0.2 dan berfungsi sampai urutan boot berubah; lalu alamat yang sama dilaporkan sebagai konflik padahal tidak ada yang berubah pada klien. Host kedua di segmen berjembatan yang sama mengklaim nilai yang sama, dan mesin yang selesai dikonfigurasi terakhir biasanya kalah. Keduanya percaya bahwa alamat itu miliknya, dan pihak yang kalah diam-diam berhenti memakai alamat yang diperintahkan untuk dipakai. Justru memperlakukannya sebagai masalah waktu itulah yang membuatnya berulang setiap reboot.

Baca bukti konflik sebelum menyentuh jembatan

Windows melaporkan konflik alamat bersama alamat perangkat keras pengklaim lainnya. Alamat perangkat keras itulah fakta yang berguna, karena memetakan ke satu antarmuka pada satu host, sementara nama tampilan peristiwa tidak memberi tahu apa pun tentang di mana duplikat berada. Catat alamat perangkat keras itu sebelum mengubah apa pun.

Deteksi duplikat berbasis ARP menyelidiki pemilik pesaing sebelum alamat dipakai dan terus mengawasi setelahnya. Karena itu host yang absen saat Anda mengonfigurasi jaringan masih bisa menyebabkan konflik satu jam kemudian. Penyelidikan bukan pemeriksaan sekali saat boot. Mesin yang muncul belakangan bisa mengambil alamat yang telah dipakai dengan tenang sepanjang hari, dan itulah sebabnya kegagalan terbaca sebagai balapan, bukan kesalahan konfigurasi.

Peristiwa konflik saja tidak mengatakan konfigurasi mana yang menciptakan klaim lainnya, dan menghapus alamat secara eksperimental merusak pemetaan yang seharusnya memberi tahu Anda. Inti bukti adalah mengubah alamat perangkat keras menjadi antarmuka yang bisa Anda periksa. Mencari inventaris berdasarkan nama mesin biasanya mengirim Anda ke host yang salah.

Inventarisasi setiap klaim di segmen

Penyiapan TAP berjembatan menyatukan segmen Ethernet yang tadinya terpisah, sehingga alamat yang unik di dalam jaringannya sendiri bisa bertabrakan begitu frame berbagi satu tautan. Karena itulah kelas kegagalan ini ada pada VPN dan tidak ada pada jaringan berute yang digantikannya. Daftar setiap kemungkinan pemilik, bukan yang pertama Anda curigai.

Telusuri daftar dengan urutan ini: alamat pada setiap perangkat jembatan dan port anggotanya, OpenVPN pool dan penetapan tetap per klien, serta setiap server DHCP yang mencakup segmen berjembatan. Lalu cocokkan alamat perangkat keras dari laporan konflik dengan antarmuka yang Anda temukan.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

Pool dan rentang DHCP adalah dua pemilik yang dilupakan orang. Cetak kedua rentang bersama-sama dan cari tumpang tindih sebelum melakukan hal lain. Alamat jembatan yang ditetapkan manual dan pool yang memberi nilai sama pasti akan bertabrakan, dan tabrakannya tampak acak sampai kedua rentang dicetak berdampingan.

Beri nomor jembatan hanya di tempat yang memerlukan identitas

Pada jembatan host normal, perangkat jembatan membawa konfigurasi lapisan ketiga host dan anggota Ethernet serta TAP bertindak sebagai port. Memberi setiap anggota alamatnya sendiri, atau menyalin satu skrip penyiapan ke beberapa mesin tanpa mengubah alamat, adalah cara satu segmen berakhir dengan tiga pemilik nilai yang sama. Anggota tidak perlu identitas sendiri untuk meneruskan frame. Mereka perlu tepat satu identitas per host yang harus dapat dijangkau di segmen itu.

Jembatan yang hanya menyaklarkan frame sama sekali tidak perlu alamat di segmen itu. Membiarkannya tanpa nomor menghapus seluruh kelas tabrakan, asalkan host masih punya jalur manajemen yang sudah Anda verifikasi. Pastikan akses dulu, hapus alamat kedua, dan periksa keterjangkauan ketiga.

Jika alamat yang akan Anda hapus adalah satu-satunya jalur ke mesin itu, menghapusnya sebagai eksperimen adalah gangguan yang Anda timbulkan sendiri, bukan diagnosis. Verifikasi jalur luar-bands sebelum menguji apa pun.

Buat koreksi bertahan melewati reboot

Mengubah antarmuka yang hidup hanya memperbaiki boot saat ini dan tidak lebih. Apa pun yang membuat ulang alamat saat boot akan mengembalikan konflik pada reboot berikutnya, dan Anda akan menyimpulkan koreksinya tidak berhasil padahal sebenarnya tidak pernah persisten. Catat file mana yang Anda ubah, agar reboot berikutnya mengonfirmasi keputusan alih-alih membuka kejutan.

Temukan pemilik konfigurasi itu: profil manajer jaringan, file per antarmuka, definisi kontainer atau VM, atau fragmen cloud-init. Ubah di sana, lalu reboot satu host terdampak dengan sengaja untuk memastikan nilai baru itulah yang kembali. Reboot adalah satu-satunya uji yang membuktikan persistensi.

Reservasikan alamat jembatan di dalam rentang DHCP sebagai pengecualian, atau pindahkan ke luarnya. Reservasi yang hanya ada di spreadsheet bukan pengecualian, dan pengalokasi tidak akan membacanya.

Buktikan dengan semua klien daring

Satu koneksi yang berhasil tidak membuktikan apa pun, karena gejala aslinya hanya muncul ketika urutannya berubah. Nyalakan setiap klien yang dimaksud, variasikan urutan boot, dan ulangi setelah menyambung ulang. Lalu restart host yang dulu kalah balapan dan pastikan alamatnya bertahan.

Untuk konfirmasi langsung, selidiki adanya pemilik duplikat sebelum menetapkan alamat dan awasi tabel tetangga sesudahnya. Jika tidak ada yang menjawab penyelidikan dan alamat tetap dimiliki secara unik sepanjang siklus reboot penuh, konfliknya terselesaikan, bukan sekadar tersembunyi. Perintah di bawah menjalankan kedua pemeriksaan pada perangkat jembatan. RFC 5227 menjelaskan perilaku penyelidikan dan pengumuman yang dijalankan alat ini, dan itulah rujukan yang dikutip ketika seseorang mengusulkan menonaktifkan deteksi.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

Penyelidikan yang tidak mendapat jawaban adalah hasil yang diharapkan pada segmen bersih. Penyelidikan yang memancing respons memberi Anda alamat perangkat keras pemilik yang tersisa, bukti yang sama yang diberikan peristiwa Windows pada awalnya. Simpan keluaran itu bersama catatan perubahan, karena itulah satu-satunya bukti bahwa alamat dimiliki secara unik.