Trafik Docker dan VM di Belakang OpenVPN: Laluan atau Nombor Semula?

Kontena dan tetamu pada hos yang menjalankan klien OpenVPN sama ada kehilangan laluan balik atau berlanggar dengan awalan terowong. Tiga soalan memilih pembaikan.

Hos melayari melalui terowong dan kontena di sebelahnya tidak mencapai apa-apa. Menerbitkan port daripada kontena yang menjalankan klien VPN sendiri lebih teruk: permintaan tiba dan balasan tidak pernah keluar. Kedua-duanya keputusan penghalaan pada hos, dan Docker hanyalah penyampai.

Tiga soalan menentukan yang mana antara dua kes yang anda hadapi, dan ia mengambil masa kira-kira seminit.

Dua kegagalan yang kelihatan sama

Yang pertama ialah masalah laluan balik. Port yang diterbitkan diterjemahkan ke dalam kontena, permintaan tiba, dan balasan dihalakan melalui laluan lalai hos, yang telah dihalakan oleh klien OpenVPN ke tun0. Balasan keluar dari alamat yang tidak dijangka oleh rakan jauh, lalu digugurkan. Yang kedua ialah perlanggaran awalan: jambatan lalai Docker memiliki 172.17.0.0/16 dan terowong korporat menolak julat yang sama.

Satu diperbaiki dengan jadual penghalaan, satu lagi dengan menomborkan semula jambatan. Menyunting sebelum tahu yang mana satu ialah cara merosakkan kontena yang berfungsi.

Tentukan dengan tiga soalan

Soalan satu: adakah kegagalan hilang apabila anda menghentikan VPN? Jika semuanya berfungsi dengan terowong dimatikan, syak laluan balik. Soalan dua: adakah ip route show table all menyenaraikan awalan yang sama dua kali, sekali pada jambatan dan sekali pada tun0? Itulah perlanggarannya. Soalan tiga: adakah alamat terjejas itu kontena, tetamu NAT atau tetamu berjambatan?

Soalan ketiga penting kerana setiap satu mempunyai pembaikan betul yang berbeza, dan menggunakan pembaikan kontena pada tetamu libvirt membazirkan satu malam.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Laluan balik: jadual untuk satu alamat sumber

Apabila trafik kontena mesti keluar melalui antara muka fizikal sementara hos sendiri menggunakan terowong, penghalaan berasaskan sumber ialah perubahan terkecil. Tambah peraturan yang sepadan dengan alamat kontena dan hantar ke jadual khusus. Tiada apa-apa lagi pada hos bergerak.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Setiap paket yang sumbernya alamat itu menyemak jadual 10 dahulu, dan jadual 10 menghantarnya ke get laluan jambatan dan bukan ke terowong.

Sahkan dengan ip route get 1.1.1.1 from 172.22.0.3. Jawapan mesti menamakan antara muka jambatan, bukan tun0. Peraturan yang ditambah begini hilang selepas but semula, jadi letakkan dalam unit atau cangkuk rangkaian yang memiliki kontena.

Corak yang sama berfungsi untuk kontena WireGuard, yang laluan balasnya juga memerlukan peraturan eksplisit.

Perlanggaran awalan: nomborkan semula jambatan

Jadual laluan menghantar satu awalan ke satu tempat. Jika VPN menolak 172.17.0.0/16 sementara jambatan Docker sudah pun di situ, metrik yang lebih rendah menang: Docker memasang laluan bersambungnya pada metrik 0, dan laluan yang ditolak tiba pada 50. Terowong kemudian kelihatan rosak sementara Docker terus berfungsi, atau sebaliknya, bergantung pada urutan pemasangan. Nomborkan semula jambatan daripada bergaduh dengan metrik.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Mulakan semula Docker selepas perubahan dan cipta semula rangkaian yang dibina dengan kolam lama. Menukar metrik hanya memindahkan konflik ke but seterusnya.

VM memerlukan jawapan lain pula

Tetamu libvirt pada rangkaian NAT lalai mewarisi penghalaan hos dan berhenti mencapai luar apabila terowong hos memiliki laluan lalai. Memindahkan tetamu ke peranti berjambatan atau macvtap memberinya laluan sendiri pada rangkaian fizikal. Dalam virt-manager, tambah perkakasan, pilih Network, tetapkan sumber kepada peranti hos macvtap, kekalkan virtio sebagai model, kemudian nyahaktifkan antara muka NAT lama.

Tetamu macvtap biasanya tidak dapat mencapai hosnya sendiri. Itu tingkah laku yang dijangka dan bukan kerosakan, dan ia termasuk dalam nota yang anda tinggalkan.

Untuk tetamu yang hanya memerlukan LAN hos, klien vendor mungkin mempunyai suis yang hilang: dengan Mullvad, mullvad lan set allow memulihkan kebolehcapaian tempatan tanpa menyentuh libvirt. Dan apabila kontena mesti boleh dicapai hanya melalui terowong, ikat port yang diterbitkan pada alamat terowong, -p 10.8.0.5:8080:8080, bukan menerbitkannya pada setiap alamat.

Artikel berkaitan