Apakah Nama Host Gateway Pi Memperbarui Rute Statis dengan Sendirinya?

Nama DNS untuk gateway Pi Anda tidak pernah menulis ulang hop berikutnya yang sudah terpasang. Lihat apa yang disimpan kernel dan siapa yang harus memperbarui rute.

Mengarahkan rute statis ke nama gateway terasa seolah harus bertahan saat alamat berubah, dan ternyata tidak. Nama itu hidup di DNS, sedangkan rute duduk di tabel perutean klien sebagai hop berikutnya yang numerik. Saat Pi pindah ke alamat lain, setiap konsumen yang sudah memasang hop lama tetap mengirim lalu lintas ke nomor yang sama. Tidak ada resolver yang terhubung ke tabel penerusan, jadi tidak ada yang menulis ulang entri itu untuk Anda.

Jawaban DNS dan rute adalah objek yang berbeda

Katakanlah Pi Anda menjawab vpn-gw.lan dan meneruskan 10.44.0.0/16 ke sebuah terowongan. Klien di 192.168.30.0/24 mencapainya lewat rute statis. Saat alamat Pi berpindah dari 192.168.30.4 ke 192.168.30.11, catatan itu mengikuti dalam masa TTL-nya dan rutenya tidak.

Kedua pandangan itu tidak sepakat dengan cara yang mudah terlewat, karena keduanya tampak masuk akal saat Anda menanyakannya secara terpisah:

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

Hanya baris pertama yang menentukan ke mana paket pergi. Baris kedua menjawab pertanyaan yang tidak pernah diajukan kernel. Catatan dengan beberapa catatan A juga tidak menjadi kebijakan failover, karena setiap alamat tetap harus menjadi hop berikutnya yang bisa dipakai di segmen itu.

Apa yang bertahan di tabel setelah perintah selesai

Rute Linux mencatat dua hal yang penting di sini: hop berikutnya sebagai alamat protokol, dan antarmuka keluar sebagai nomor indeks. Atribut rute rtnetlink menamai bidang pertama itu RTA_GATEWAY, dan isinya byte. Begitu entri terpasang, tidak ada TTL yang menempel padanya dan tidak ada pencarian latar yang menyegarkannya.

Itulah sebabnya ip route add 10.44.0.0/16 via vpn-gw.lan bisa tampak berhasil. Alat itu menyelesaikan nama saat perintah berjalan, menulis alamat hasilnya, dan melupakan namanya sepenuhnya. Jalankan ip route show 10.44.0.0/16 sesudahnya dan Anda mendapat alamat literal kembali.

Perilaku itu layak diketahui sebelum Anda menyalahkan terowongan.

Alat yang menyelesaikan nama untuk Anda, dan kapan

Sebagian router dan firewall memang menerima nama host di bidang rute atau gateway. Yang penting adalah kapan penyelesaiannya terjadi. Jika perangkat hanya menyelesaikan nama saat Anda menerapkan konfigurasi, entri yang tersimpan sama statisnya dengan alamat yang diketik, dan perubahan alamat berikutnya memerlukan penerapan lagi. Fakta bahwa bidang itu menerima nama tidak memberi tahu apa pun tentang penyegaran.

Penyiapan terkelola cenderung membagi pekerjaan. Reservasi DHCP atau sewa statis menjaga Pi pada satu alamat, dan catatan DNS cukup mengikuti sewa itu. Tidak ada yang perlu melacak target yang bergerak karena targetnya tidak bergerak.

Pembaru yang dipantau adalah pola sah lainnya, dan ia butuh pemilik.

Patok alamatnya atau jalankan sendiri pembarunya

Untuk LAN kecil, reservasi di server DHCP adalah perbaikan termurah. Pilih alamat di luar kumpulan dinamis, ikat ke alamat MAC Pi, dan pastikan dengan ip -4 addr show dev eth0 setelah pembaruan sewa berikutnya. Lalu arahkan hop berikutnya klien ke alamat itu satu kali. Sekarang Anda punya gateway yang stabil dan catatan yang menggambarkannya, dan itulah urutan yang benar-benar dipakai hubungan ini.

Jika Pi memang harus pindah, simpan perbaikan rute di satu tempat alih-alih mengedit setiap klien dengan tangan. Skrip pendek yang menyelesaikan, membandingkan, dan mengganti sudah cukup untuk membuat langkah itu bisa diulang:

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

Perintah terakhir adalah uji penerimaan, karena ia mencetak gateway yang benar-benar akan dipakai kernel. Jika alamat yang tercetak masih yang lama, skrip berjalan di ruang nama jaringan yang salah atau tidak punya izin, dan sisi DNS tidak relevan.

Periksa juga jalur kembali. Pi harus tahu cara mencapai subnet klien, dan firewall-nya harus mengizinkan lalu lintas terowongan. Rute default yang ditambahkan untuk menutupi ketidakcocokan biasanya menyembunyikan celah sebenarnya dan merusak hal lain seminggu kemudian.

Artikel terkait