Kontainer dengan dua jaringan memilih gateway yang salah

Dua lampiran, satu rute default, dan jaringan yang salah selalu menang. Sematkan jalur keluar dengan Compose gw_priority dan pastikan dari dalam kontainer.

Kontainer Anda masih menjawab di jembatan kontrolnya, tetapi setiap paket keluar meninggalkan jaringan melalui macvlan kantor. Tidak ada yang gagal. Dua lampiran masing-masing menyediakan gateway, dan satu-satunya rute default pergi ke jaringan yang tidak Anda maksud, sehingga layanan tetap berjalan sementara lalu lintasnya menempuh jalur yang lebih panjang. Saat seseorang menyadarinya, buktinya adalah tabel perutean, bukan pesan galat.

Penjelasan yang biasa adalah Docker memilih jaringan secara kebetulan. Dalam praktiknya keputusan lama mengikuti urutan abjad nama jaringan yang terpasang, yang menjadikan perutean sebagai efek samping sebuah label. gw_priority menggantinya dengan angka yang Anda pilih dengan sengaja, dan mengadopsinya memakan waktu sekitar satu menit setelah tata letaknya ditulis.

Mengapa rute default mendarat di jaringan yang salah

Setiap jaringan yang dimasuki layanan dapat menawarkan gateway-nya sendiri, dan kontainer tetap berakhir dengan tepat satu rute default. Sebelum Compose 2.33.1, seri ditentukan dengan mengurutkan nama jaringan, sehingga label seperti control yang datang sebelum office menentukan ke mana lalu lintas pergi. Tidak ada apa pun di dalam kontainer yang mencatat bahwa keputusan itu sewenang-wenang, itulah sebabnya keputusan itu lolos tinjauan kode dan muncul kemudian sebagai jalur yang aneh. Menaruh kebijakan di berkas compose adalah satu-satunya cara membuat pilihan itu dapat diperiksa.

Dua hal benar-benar mengubah jaringan mana yang menang: nilai gw_priority yang Anda tetapkan, dan jaringan mana yang terpasang sama sekali. Tambahkan jaringan ketiga dan himpunan kandidat bertambah; lepaskan macvlan dan tidak ada lagi yang bersaing dengan jembatan. Tak satu pun dari keduanya muncul di log aplikasi, karena rute default yang salah jarang memutus koneksi sepenuhnya. Itu hanya membuat balasan datang dari alamat yang mungkin tidak diharapkan pihak lain.

Sematkan gateway dengan gw_priority

Compose mengekspos gw_priority pada setiap lampiran layanan-ke-jaringan sejak versi 2.33.1, dan angka tertinggi menang. Tidak ada kunci gateway per layanan, jadi nilainya berada di blok networks layanan tersebut. Contoh di bawah menyerahkan rute default kepada control sementara office tetap terjangkau untuk LAN yang terhubung langsung.

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

Baca blok itu sebagai dua kendali terpisah: gw_priority menentukan rute default, dan bagian ipam menentukan pengalamatan. Mengubah hanya subnet membiarkan pilihan jalur keluar tidak tersentuh, dan itulah cara paling umum perbaikan ini diterapkan setengah jalan. Simpan prioritas di sebelah jaringan yang mereka kendalikan agar pembaca berikutnya tidak perlu mencari keputusan itu.

Jangan mencampur gw_priority dengan properti priority biasa di sebelahnya. Properti itu mengurutkan pembuatan koneksi dan tidak mengatakan apa pun tentang perutean, jadi ia tidak dapat memilih gateway default dan tidak memperbaiki penamaan antarmuka. Jika seseorang menyarankan menaikkan priority untuk mengarahkan lalu lintas, sarannya salah meskipun urutan yang dihasilkan kebetulan tampak benar.

Verifikasi jaringan mana yang benar-benar membawa rute default

Periksa di dalam kontainer yang berjalan, karena tabel perutean host menggambarkan host dan bukan ruang nama yang dipakai layanan. Jalankan pemeriksaan konfigurasi lebih dahulu agar salah ketik gagal sebelum restart, lalu baca rute yang benar-benar dipasang kontainer.

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

Hasil yang benar menyebut perangkat jembatan dan 172.30.50.1; hasil yang salah menyebut 192.168.120.1 dan perangkat macvlan. Jika image tidak menyertakan paket iproute2, berkas /proc tetap melaporkan rute default, dengan tujuan 00000000 dan byte gateway terbalik. Bandingkan kolom antarmuka dengan docker inspect ketika nama perangkat tidak jelas.

Macvlan adalah port fisik, bukan klon jembatan

Macvlan memberi kontainer identitas kedua di kabel, dan itulah yang membuat akses ke perangkat lokal berfungsi. Itu juga berarti port switch dan hypervisor harus menerima alamat MAC tambahan, dan banyak jaringan cloud diam-diam menolaknya. Uji satu kontainer sebelum merencanakan armada, karena MAC yang ditolak biasanya muncul sebagai tautan yang menyala tetapi tidak meneruskan apa pun.

Pengaturan macvlan_mode: bridge adalah mode pengandar macvlan, bukan jembatan perangkat lunak Docker, dan passthru adalah mode khusus tersendiri, bukan nilai default. Linux juga mencegah kontainer macvlan menjangkau hostnya sendiri melalui induk yang sama, dan itulah alasan mempertahankan jembatan kontrol alih-alih mengharapkan satu lampiran mengerjakan kedua tugas.

Beri nama induk VLAN sebelum Compose melihatnya

Docker memperlakukan induk bertitik seperti eno1.120 sebagai subantarmuka 802.1Q dan membuat perangkat VLAN sendiri. Kenyamanan itu punya batas: nama turunannya bergantung pada nama antarmuka fisik, dan nama panjang dapat mendorong hasilnya melewati apa yang diharapkan perkakas di sekitarnya. Membuat antarmuka VLAN bernama di konfigurasi jaringan host dan mengarahkan parent ke sana menjaga kedua ujung tetap dapat diprediksi.

Ingat bahwa kunci di bawah networks adalah nama Compose, bukan perangkat Linux. Mencari antarmuka bernama office di host akan gagal, karena kernel hanya melihat antarmuka induk dan pasangan veth di belakang kontainer.

Sediakan ruang untuk VPN di atasnya

Klien VPN terpasang setelah jaringan ini ada, jadi ia dapat menambahkan rute yang lebih spesifik, aturan kebijakan, dan filter terlepas dari gw_priority. Rencanakan prefiks jarak jauh terhadap kedua subnet lokal, termasuk balasan yang dibutuhkan jalur kontrol. Ketika prefiks jarak jauh tumpang tindih dengan LAN kantor, perbaiki rencana alamat alih-alih mencabut seluruh rentang privat dari terowongan.

Periksa ulang alamat, rute, dan jalur layanan setelah VPN mulai dan sekali lagi setelah VPN terhubung kembali, karena pada saat menyambung ulang itulah rute yang ditambahkan dengan tangan menghilang. Tuliskan tabel yang diharapkan sebelum uji pertama agar perbandingan sesudahnya adalah diff, bukan latihan ingatan. Pertahankan kepemilikan jaringan yang tetap di Compose dan biarkan konfigurasi VPN hanya memiliki kebijakannya sendiri.

Artikel terkait