Mengapa peringatan flush rute vpnc muncul di dalam kontainer

Flush cache rute adalah sisa dari kernel yang tidak lagi menyimpan cache itu; galat hanya-baca berasal dari mount kontainer, bukan dari tunnel.

Log kontainer baru sering berakhir pada keluhan Read-only file system tentang /proc/sys/net/ipv4/route/flush, dan baris itu disalahkan atas tunnel yang mungkin sepenuhnya sehat. Penulisan di baliknya menyasar entri kernel yang tidak lagi melakukan hal berguna setelah cache rute IPv4 hilang. Di dalam kontainer /proc/sys di-mount hanya-baca, sehingga pengalihan ditolak sebelum ada nilai yang masuk dan shell mencetak penolakan itu. Tunnel yang berfungsi dapat mencetak peringatan ini selama baris lama tetap ada di skrip, dan --privileged tidak pernah membuat penulisan itu berarti.

Apa yang coba dibersihkan skrip

Skrip koneksi lama berakhir dengan pembersihan cache: menulis nilai ke berkas kendali kernel dan meminta tumpukan IPv4 membuang cache peruteannya, agar rute tunnel baru dipilih tanpa menunggu entri usang kedaluwarsa. Berkas itu dialamatkan di bawah /proc/sys/net/ipv4/, yang menjadikan operasi tersebut pengalihan shell, bukan perintah perutean. Kernel 3.6 menghapus cache itu, dan bersamanya alasan keberadaan flush. Tidak ada apa pun di jalur data saat ini yang bergantung pada penulisan itu.

Entri itu sendiri bertahan sebagai berkas lama yang hanya-bisa-ditulis, sehingga skrip yang masih menulis ke sana mencapai jalur nyata dan pemeriksaan izin nyata. Di host penulisan mengembalikan sukses dan tidak mengubah apa pun. Di kontainer pengalihan yang sama menabrak /proc/sys hanya-baca dan gagal dengan EROFS, yang dicetak shell sebagai pesan sistem berkas hanya-baca. Pada kernel yang jalurnya benar-benar tidak ada, redaksinya menjadi No such file or directory, dan kesimpulannya tidak berubah.

Kedua galat mengatakan hal berbeda, dan perbedaannya layak dijaga tetap jelas. Read-only file system berarti kernel mencapai entri dan menolak penulisan; No such file or directory berarti entrinya sudah hilang. Tidak ada pesan yang melaporkan perangkat tunnel, rute, atau resolusi nama, jadi tidak satu pun dapat membenarkan hak istimewa tambahan.

Urutanlah yang membuat pesan tampak kausal. Skrip koneksi memasang rute, mengubah status antarmuka, dan menulis ulang resolusi nama sebelum mencapai pembersihan di akhir, jadi baris terakhir yang dicetak adalah baris yang dikutip orang bahkan ketika setiap langkah penting mengembalikan sukses. Tunnel yang terbentuk dan membawa lalu lintas sambil mencetak peringatan ini persis cocok dengan mekanisme di atas.

Periksa mount dan rute sebelum menambah hak istimewa

Tiga pembacaan memisahkan peringatan kosmetik dari kegagalan nyata: apakah skrip terpasang masih membawa baris itu, bagaimana /proc/sys di-mount, dan ke mana lalu lintas aplikasi sebenarnya pergi. Jalankan di ruang nama kontainer yang sama atau di host tempat peringatan muncul, karena pemeriksaan di mesin yang tidak terkait menjawab pertanyaan lain.

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

Jawaban grep lebih lemah daripada kelihatannya, karena temuan membuktikan baris itu ada, bukan bahwa baris itu berjalan tanpa penjagaan; skrip yang terawat dapat membawa penulisan di dalam penjagaan yang melewatinya. findmnt -no OPTIONS /proc/sys menetapkan mount secara langsung, dan ro dalam keluaran itu berarti setiap penulisan di bawah titik itu ditolak, apa pun yang dilakukan skrip. Pencarian rute kemudian menunjukkan apakah tujuan yang dibutuhkan aplikasi diselesaikan melalui antarmuka tunnel atau melalui gateway default kontainer. Pencarian yang memilih gateway default berarti tunnel sudah naik dan tidak ada yang dirutekan ke dalamnya, yang merupakan masalah perutean dan bukan masalah hak istimewa.

Dari mana perbaikan sebenarnya datang

Perbaikan terawat hidup di skrip, bukan di flag kontainer. upstream vpnc-script telah mengubah cara menangani operasi ini, jadi bandingkan salinan di dalam image dengan upstream saat ini dan perbarui melalui paket atau build image yang menyediakannya. Berkas yang diedit tangan di dalam kontainer yang berjalan tidak dapat ditinjau dan tidak akan bertahan pada build berikutnya.

--privileged didokumentasikan memberikan semua kapabilitas plus akses perangkat yang luas, konsesi besar untuk pesan yang tidak mengubah apa pun, jadi sebutkan kapabilitas yang hilang jika memang ada yang benar-benar tidak ada. Setelah pembaruan, ulangi pencarian rute dan biarkan aplikasi memakai tunnel, karena log yang tenang dan koneksi yang berfungsi adalah hasil terpisah.

Artikel terkait