Trafik Docker dan VM di Balik OpenVPN: Rutekan atau Nomori Ulang?

Host menjelajah melalui terowongan dan kontainer di sampingnya tidak menjangkau apa pun. Menerbitkan porta dari kontainer yang menjalankan klien VPN sendiri lebih buruk: permintaan tiba dan balasannya tidak pernah keluar. Keduanya keputusan perutean di host, dan Docker hanya pembawa pesan.

Tiga pertanyaan menentukan mana dari dua kasus yang Anda hadapi, dan butuh sekitar satu menit.

Dua kegagalan yang tampak sama

Yang pertama adalah masalah jalur balik. Porta yang diterbitkan diterjemahkan ke dalam kontainer, permintaan tiba, dan balasannya dirutekan melalui rute bawaan host, yang telah diarahkan klien OpenVPN ke tun0. Balasan keluar dari alamat yang tidak diharapkan rekan jauh, lalu dibuang. Yang kedua adalah tabrakan prefiks: jembatan bawaan Docker memiliki 172.17.0.0/16 dan terowongan korporat mendorong rentang yang sama.

Satu diperbaiki dengan tabel perutean, yang lain dengan menomori ulang sebuah jembatan. Menyunting sebelum tahu mana yang mana adalah cara merusak kontainer yang berfungsi.

Putuskan dengan tiga pertanyaan

Pertanyaan satu: apakah kegagalan hilang saat Anda menghentikan VPN? Jika semuanya bekerja dengan terowongan mati, curigai jalur balik. Pertanyaan dua: apakah ip route show table all mencantumkan prefiks yang sama dua kali, sekali di jembatan dan sekali di tun0? Itulah tabrakannya. Pertanyaan tiga: apakah alamat yang terdampak itu kontainer, tamu NAT, atau tamu yang dijembatani?

Pertanyaan ketiga penting karena masing-masing punya perbaikan yang benar dan berbeda, dan menerapkan perbaikan kontainer pada tamu libvirt membuang satu malam.

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

Jalur balik: tabel untuk satu alamat sumber

Ketika trafik kontainer harus keluar melalui antarmuka fisik sementara host sendiri memakai terowongan, perutean berbasis sumber adalah perubahan terkecil. Tambahkan aturan yang cocok dengan alamat kontainer dan kirimkan ke tabel khusus. Tidak ada yang lain bergeser di host.

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 memeriksa tabel 10 lebih dulu, dan tabel 10 mengirimnya ke gateway jembatan alih-alih ke terowongan.

Pastikan dengan ip route get 1.1.1.1 from 172.22.0.3. Jawabannya harus menyebut antarmuka jembatan, bukan tun0. Aturan yang ditambahkan seperti ini hilang saat reboot, jadi taruh di unit atau kait jaringan yang memiliki kontainer.

Pola yang sama berlaku untuk kontainer WireGuard, yang jalur balasannya juga perlu aturan eksplisit.

Tabrakan prefiks: nomori ulang jembatan

Tabel rute mengirim satu prefiks ke satu tempat. Jika VPN mendorong 172.17.0.0/16 sementara jembatan Docker sudah ada di sana, metrik yang lebih rendah menang: Docker memasang rute terhubungnya pada metrik 0, dan rute yang didorong tiba pada 50. Terowongan lalu tampak rusak sementara Docker terus bekerja, atau sebaliknya, tergantung urutan pemasangan. Nomori ulang jembatan alih-alih berkelahi dengan metrik.

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

Mulai ulang Docker setelah perubahan dan buat ulang jaringan yang dibangun dengan kumpulan lama. Mengubah metrik hanya memindahkan konflik ke boot berikutnya.

VM butuh jawaban lain lagi

Tamu libvirt pada jaringan NAT bawaan mewarisi perutean host dan berhenti menjangkau luar begitu terowongan host memiliki rute bawaan. Memindahkan tamu ke perangkat jembatan atau macvtap memberinya jalur sendiri di jaringan fisik. Di virt-manager, tambahkan perangkat keras, pilih Network, atur sumber ke perangkat host macvtap, pertahankan virtio sebagai model, lalu nonaktifkan antarmuka NAT lama.

Tamu macvtap biasanya tidak dapat menjangkau host-nya sendiri. Itu perilaku yang diharapkan, bukan kerusakan, dan termasuk dalam catatan yang Anda tinggalkan.

Untuk tamu yang hanya butuh LAN host, klien vendor mungkin memiliki sakelar yang hilang: dengan Mullvad, mullvad lan set allow memulihkan keterjangkauan lokal tanpa menyentuh libvirt. Dan bila kontainer harus dapat dijangkau hanya melalui terowongan, ikat porta yang diterbitkan ke alamat terowongan, -p 10.8.0.5:8080:8080, alih-alih menerbitkannya di setiap alamat.