Mengapa kontena macvlan tidak boleh membalas klien VPN

Bayangkan hos Linux yang menamatkan VPN dan pada masa sama menjalankan kontena pada rangkaian macvlan. LAN ialah 192.168.60.0/24, kontena memegang 192.168.60.210, dan klien VPN datang dari 10.95.0.0/24. Klien sampai ke perkhidmatan, balasan tidak pernah kembali, dan setiap peraturan tembok api pada hos kelihatan betul. Dua kekangan berasingan menghasilkan simptom itu, dan membaiki satu membiarkan yang lain di tempatnya.

Dua kekangan, satu simptom

Kekangan pertama ialah pengasingan: pemacu macvlan Docker tidak membenarkan kontena bercakap dengan hosnya sendiri melalui antara muka induk. Trafik antara tindanan hos dan kontena tiada laluan, tidak kira bagaimana laluan pada hos ditulis.

Kekangan kedua ialah laluan pulang. Gateway lalai kontena biasanya penghala LAN, jadi balasan yang dialamatkan kepada klien VPN keluar melalui penghala itu. Jika penghala tiada laluan kembali ke kolam VPN, balasan itu digugurkan di suatu tempat di tengah.

Kedua-dua kegagalan kelihatan serupa dari sudut klien: permintaan yang tiba dan jawapan yang tidak pernah datang. Kedua-duanya memerlukan pembaikan berbeza, dan peraturan masquerade yang luas boleh menyembunyikan yang mana masih rosak. Itulah sebabnya ujian pertama ialah tangkapan di sebelah kontena dan bukan satu lagi perubahan tembok api. Jika permintaan itu tidak pernah muncul di sana, kekangan pengasingan yang sedang berlaku.

Bina shim sebelah hos secara sempit

Antara muka macvlan kedua pada hos, disambungkan kepada induk yang sama dalam mod jambatan, memberi tindanan hos identitinya sendiri pada segmen LAN itu. Rizab alamat di luar kolam DHCP dan di luar julat kontena untuknya, dan halakan hanya kontena melaluinya.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Perintah pertama mencipta antara muka dalam mod jambatan, iaitu nilai lalai berdokumen untuk pemacu ini dan mod yang anda mahu untuk trafik hos-kontena. Yang kedua memberikan /32 supaya alamat tidak berlanggar dengan awalan LAN, dan yang keempat menghantar hanya alamat kontena melalui shim.

Jangan ubah hala seluruh LAN melalui antara muka baharu. Laluan bersambung biasa kekal seperti sedia ada, dan laluan hos sengaja sempit supaya satu kontena mendapat laluan tanpa bahagian lain segmen itu mengubah tingkah lakunya. Laluan lalai yang menunjuk ke shim akan menjadi reka bentuk lain dengan akibat lain. Kekalkan ia khusus dan jejari kerosakan kekal kecil.

Perintah ini mengubah tetapan rangkaian pada hos yang sedang berjalan. Pada perkakas atau platform terurus, gunakan mekanisme konfigurasi yang disokong platform itu, kerana perubahan interaktif dalam root shell mungkin tidak bertahan selepas peningkatan.

Tentukan bagaimana sumber dikekalkan

Dengan shim di tempatnya, kontena boleh sampai ke hos, dan persoalannya menjadi alamat sumber apa yang dibawa balasan. Mengekalkan sumber VPN asal ialah model yang lebih bersih: kontena melihat alamat sebenar klien, dan log serta peraturan akses perkhidmatan boleh menggunakannya.

Agar itu berfungsi, konfigurasi rangkaian kontena mesti menghantar trafik untuk 10.95.0.0/24 ke 192.168.60.250 sebagai gateway bagi laluan ini. Itu tetapan laluan atau gateway yang disokong dalam konfigurasi kontena itu sendiri, bukan helah di sebelah hos. Sahkan dari dalam kontena daripada menganggap tetapan itu telah berkuat kuasa. Gateway lalai yang masih menunjuk ke penghala LAN akan terus menghantar balasan ke lubang yang sama.

Jika reka bentuk yang diluluskan menyembunyikan sumber VPN sebaliknya, hadkan terjemahan secara sempit: kolam VPN sebenar, shim sebagai antara muka keluar, dan kontena serta perkhidmatan yang khusus.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Padankan shim sebagai antara muka keluar, bukan terowong. Peraturan yang menamakan terowong sebagai antara muka keluar tidak akan sepadan dengan paket yang menuju ke kontena, dan itulah kesilapan yang biasanya ada dalam susunan sebegini. Kekalkan peraturan sesempit ayat di atas dan semak semula apabila kolam berubah.

Sahkan dari klien, bukan dari hos

Permintaan dari hos itu sendiri, terikat pada alamat shim, membuktikan bahawa shim boleh sampai ke kontena. Ia tidak membuktikan bahawa kontena boleh menghantar trafik kembali ke sumber 10.95.0.x yang dikekalkan, kerana alamat sumber dalam ujian itu ialah alamat shim sendiri.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Perintah pertama menguji bahagian hos ke kontena, dan yang kedua menunjukkan apa yang sebenarnya melintasi shim semasa klien VPN sebenar membuat permintaan. Lihat alamat sumber di laluan masuk dan sama ada balasan muncul dengan aliran yang sama.

Pemajuan mesti diaktifkan pada hos, dan laluan pemajuan memerlukan kebenaran untuk kolam VPN ke shim pada port perkhidmatan serta balasan yang telah terbentuk. Peraturan INPUT pada hos tidak membenarkan trafik yang dimajukan, dan itu sebab biasa paket digugurkan selepas penghalaan kelihatan betul.

Jalankan aplikasi sebenar dengan kelayakan sebenar, kemudian periksa sama ada perkhidmatan kedua yang tidak berkaitan pada kontena yang sama masih menolak anda. Jika satu-satunya cara untuk menjayakannya ialah membuka setiap peraturan pemajuan, reka bentuk belum selesai. Catat juga alamat sumber yang direkodkan perkhidmatan, kerana itulah yang akan digunakan oleh peraturan aksesnya sendiri mulai sekarang.