Kontena dengan dua rangkaian memilih gateway yang salah

Dua lampiran, satu laluan lalai, dan rangkaian yang salah terus menang. Sematkan jalan keluar dengan Compose gw_priority dan sahkan dari dalam kontena.

Kontena anda masih menjawab pada jambatan kawalannya, tetapi setiap paket keluar meninggalkan rangkaian melalui macvlan pejabat. Tiada apa yang gagal. Dua lampiran masing-masing membekalkan gateway, dan satu-satunya laluan lalai pergi ke rangkaian yang anda tidak niatkan, jadi perkhidmatan terus berjalan sementara trafiknya mengambil laluan yang lebih panjang. Apabila seseorang menyedarinya, buktinya ialah jadual penghalaan dan bukan mesej ralat.

Penjelasan biasa ialah Docker memilih rangkaian secara tidak sengaja. Dalam amalan keputusan lama mengikut susunan abjad nama rangkaian yang dilampirkan, yang menjadikan penghalaan sebagai kesan sampingan sesuatu label. gw_priority menggantikannya dengan nombor yang anda pilih dengan sengaja, dan menerimanya mengambil masa kira-kira satu minit selepas susun atur ditulis.

Mengapa laluan lalai mendarat pada rangkaian yang salah

Setiap rangkaian yang disertai perkhidmatan boleh menawarkan gateway sendiri, dan kontena tetap berakhir dengan tepat satu laluan lalai. Sebelum Compose 2.33.1, seri diselesaikan dengan mengisih nama rangkaian, jadi label seperti control yang datang sebelum office menentukan ke mana trafik pergi. Tiada apa pun di dalam kontena merekodkan bahawa keputusan itu sewenang-wenangnya, sebab itulah ia melepasi semakan kod dan muncul kemudian sebagai laluan yang pelik. Meletakkan dasar dalam fail compose ialah satu-satunya cara menjadikan pilihan itu boleh diperiksa.

Dua perkara benar-benar mengubah rangkaian mana yang menang: nilai gw_priority yang anda tetapkan, dan rangkaian mana yang dilampirkan sama sekali. Tambah rangkaian ketiga dan set calon bertambah; buang macvlan dan tiada apa lagi untuk bersaing dengan jambatan. Kedua-dua langkah tidak muncul dalam log aplikasi, kerana laluan lalai yang salah jarang memutuskan sambungan sepenuhnya. Ia hanya membuat balasan tiba dari alamat yang mungkin tidak dijangka pihak lain.

Sematkan gateway dengan gw_priority

Compose mendedahkan gw_priority pada setiap lampiran perkhidmatan-ke-rangkaian sejak versi 2.33.1, dan nombor tertinggi menang. Tiada kunci gateway bagi setiap perkhidmatan, jadi nilainya terletak di bawah blok networks perkhidmatan itu. Contoh di bawah memberikan laluan lalai kepada control sementara office kekal boleh dicapai untuk LAN yang bersambung terus.

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 kawalan berasingan: gw_priority menentukan laluan lalai, dan bahagian ipam menentukan pengalamatan. Menukar subnet sahaja membiarkan pilihan jalan keluar tidak tersentuh, dan itulah cara paling biasa pembetulan ini digunakan separuh jalan. Simpan keutamaan di sebelah rangkaian yang dikawalnya supaya pembaca seterusnya tidak perlu mencari keputusan itu.

Jangan kelirukan gw_priority dengan sifat priority biasa di sebelahnya. Itu menyusun penciptaan sambungan dan tidak berkata apa-apa tentang penghalaan, jadi ia tidak boleh memilih gateway lalai dan tidak membetulkan nama antara muka. Jika seseorang mencadangkan menaikkan priority untuk mengarahkan trafik, cadangan itu salah walaupun susunan yang terhasil kebetulan kelihatan betul.

Sahkan rangkaian mana yang benar-benar membawa laluan lalai

Periksa di dalam kontena yang berjalan, kerana jadual penghalaan hos menerangkan hos dan bukan ruang nama yang digunakan perkhidmatan. Jalankan pemeriksaan konfigurasi dahulu supaya salah taip gagal sebelum mula semula, kemudian baca laluan yang benar-benar dipasang oleh kontena.

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

Hasil yang betul menamakan peranti jambatan dan 172.30.50.1; hasil yang salah menamakan 192.168.120.1 dan peranti macvlan. Jika imej tidak mengandungi pakej iproute2, fail /proc masih melaporkan laluan lalai, dengan destinasi 00000000 dan bait gateway terbalik. Bandingkan lajur antara muka dengan docker inspect apabila nama peranti tidak jelas.

Macvlan ialah port fizikal, bukan klon jambatan

Macvlan memberikan kontena identiti kedua pada kabel, dan itulah yang menjadikan akses kepada peranti tempatan berfungsi. Ia juga bermakna port suis dan hypervisor mesti menerima alamat MAC tambahan, dan banyak rangkaian awan menolaknya secara senyap. Uji satu kontena sebelum merancang armada, kerana MAC yang ditolak biasanya muncul sebagai pautan yang hidup tetapi tidak melepaskan apa-apa.

Tetapan macvlan_mode: bridge ialah satu mod pemacu macvlan, bukan jambatan perisian Docker, dan passthru ialah mod khusus yang berasingan dan bukan nilai lalai. Linux juga menghalang kontena macvlan daripada mencapai hosnya sendiri melalui induk yang sama, dan itulah sebabnya jambatan kawalan dikekalkan dan bukannya mengharapkan satu lampiran melakukan kedua-dua tugas.

Namakan induk VLAN sebelum Compose melihatnya

Docker menganggap induk bertitik seperti eno1.120 sebagai sub-antara muka 802.1Q dan mencipta peranti VLAN sendiri. Kemudahan itu ada hadnya: nama terbitan bergantung pada nama antara muka fizikal, dan nama panjang boleh menolak hasilnya melebihi apa yang dijangka oleh alat di sekelilingnya. Mencipta antara muka VLAN bernama dalam konfigurasi rangkaian hos dan menghalakan parent kepadanya menjadikan kedua-dua hujung boleh diramal.

Ingat bahawa kunci di bawah networks ialah nama Compose, bukan peranti Linux. Mencari antara muka bernama office pada hos akan gagal, kerana kernel hanya melihat antara muka induk dan pasangan veth di belakang kontena.

Sediakan ruang untuk VPN di atas

Klien VPN dipasang selepas rangkaian ini wujud, jadi ia boleh menambah laluan yang lebih khusus, peraturan dasar dan penapis tanpa mengira gw_priority. Rancang awalan jauh terhadap kedua-dua subnet tempatan, termasuk balasan yang diperlukan oleh laluan kawalan. Apabila awalan jauh bertindih dengan LAN pejabat, betulkan pelan alamat dan bukannya mencabut seluruh julat peribadi daripada terowong.

Semak semula alamat, laluan dan laluan perkhidmatan selepas VPN bermula dan sekali lagi selepas ia menyambung semula, kerana semasa menyambung semula itulah laluan yang ditambah dengan tangan hilang. Tulis jadual yang dijangka sebelum ujian pertama supaya perbandingan selepas itu ialah diff dan bukan latihan ingatan. Kekalkan pemilikan rangkaian yang berterusan dalam Compose dan biarkan konfigurasi VPN hanya memiliki dasarnya sendiri.

Artikel berkaitan