Mengapa perkhidmatan Linux awam anda membalas melalui VPN

Tiada apa-apa dalam soket mengingati antara muka mana yang membawa permintaan itu, jadi laluan lalai VPN terowong penuh boleh menangkap balasan yang sepatutnya ke WAN. Perkhidmatan itu tidak mengabaikan antara muka masuk; Linux menghalakan balasan yang dijana secara tempatan mengikut destinasi dan dasar sumber. Peraturan berasaskan sumber boleh menghantar hanya balasan perkhidmatan melalui jadual WAN lengkap, dan membiarkan keluar biasa kekal di terowong. Port kekal terbuka semasa balasan keluar melalui laluan yang salah, sebab itulah simptom kelihatan sebelah pihak.

Salah faham: balasan mengikut antara muka tempat ia tiba

Nampak logik bahawa paket yang tiba di eth0 harus keluar di eth0. Penapis paket tanpa keadaan boleh ditulis begitu, dan tcpdump di sisi masuk menunjukkan permintaan tepat di tempat yang dijangka. Penghalakan tidak berfungsi begitu untuk trafik yang dihasilkan oleh hos itu sendiri.

Sebaik sahaja perkhidmatan menerima sambungan, balasannya ialah paket baharu yang dijana secara tempatan. Kernel menyemak peraturan penghalakan untuk destinasi dan sumber balasan, dan laluan lalai VPN ialah jawapan yang sah sepenuhnya. Tiada apa-apa dalam soket mengingati antara muka mana yang membawa permintaan itu.

Sebab itulah simptom kelihatan sebelah pihak: permintaan tiba, balasan hilang. Sebab itu juga menambah peraturan tembok api untuk port masuk tidak mengubah apa-apa. Paket itu tidak disekat di laluan masuk; ia dihalakan ke tempat lain di laluan keluar. Jejaki balasan dengan carian yang dikelaskan mengikut sumber dan lencongan itu akan kelihatan.

Apa yang sebenarnya dihalakan oleh kernel: alamat sumber

Pemegang yang anda perlukan ialah alamat tempatan yang digunakan oleh perkhidmatan untuk balasan. Pada hos dengan alamat eth0 ilustratif 192.0.2.10/24 dan get laluan 192.0.2.1, alamat itu ada pada antara muka. Pada VM awan, alamat awam mungkin diterjemah di hulu dan tiada dalam tetamu, jadi gunakan alamat yang benar-benar dipegang oleh hos.

Periksa keadaan semasa sebelum menempah nombor jadual atau keutamaan peraturan. Peraturan dasar sedia ada boleh menaungi peraturan baharu, dan jadual lama dengan nombor yang sama mungkin sudah membawa laluan tidak berkaitan:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Kemudian pilih jadual mengikut sumber. Peraturan itu sepadan dengan balasan yang sudah membawa 192.0.2.10, iaitu tepat trafik yang tamat secara tempatan yang ingin anda kecualikan. Trafik yang dihalakan ke hadapan dan paket dari alamat tempatan lain tidak sepadan.

Bina jadual pulangan yang lengkap, bukan separuh laluan lalai

Jadual yang hanya mempunyai laluan lalai tidak mencukupi. Kernel masih perlu menyelesaikan get laluan, dan penyelesaian itu memerlukan awalan bersambung dalam jadual yang sama. Jadual yang ketiadaan awalan itu gagal pada penyelesaian get laluan walaupun laluan lalainya kelihatan betul. Tambah kedua-duanya, kemudian arahkan peraturan sumber ke jadual itu:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Gunakan awalan dan get laluan sebenar dan bukan menyalin contoh. Antara muka awan yang dikonfigurasikan sebagai /32 dengan get laluan on-link memerlukan laluan bersambung yang berbeza, dan jadual yang dibina daripada awalan yang salah gagal pada lompatan pertama. Atribut src menyatakan sumber pilihan untuk laluan itu; ia tidak menggantikan peraturan sumber.

Urutan juga penting. Peraturan luas dengan nombor keutamaan lebih rendah dinilai dahulu, jadi peraturan sumber mesti dicapai sebelum mana-mana peraturan yang akan menghantar trafik ini kembali ke jadual utama. Periksa keutamaan dengan ip rule show selepas menambahnya, bukan hanya semasa but.

Sahkan dengan carian yang dikelaskan mengikut sumber

Minta kernel menghalakan destinasi ujian dari alamat perkhidmatan. Jawapannya harus menyebut eth0 dan get laluan WAN, bukan terowong:

ip -4 route get 198.51.100.25 from 192.0.2.10

Kemudian buat sambungan sah yang baharu dan perhatikan kedua-dua arah. Carian yang memilih jadual yang betul sementara sambungan langsung masih gagal menunjukkan penapisan laluan balik atau peraturan tembok api, bukan jadual itu. Periksa kawalan itu sebelum melumpuhkan apa-apa secara global.

Letakkan laluan akhir dan peraturan di bawah pengurus rangkaian yang memiliki antara muka itu. Perubahan alamat, pembaharuan DHCP dan sambungan semula VPN semuanya menulis semula keadaan kernel, dan peraturan yang ditambah dengan tangan hilang atau menunjuk ke get laluan usang selepas peristiwa seterusnya.

Di mana pengecualian ini berhenti

Peraturan itu mengecualikan trafik yang tamat secara tempatan daripada satu alamat sumber. Ia tidak meliputi port yang diterbitkan oleh Docker, DNAT atau perkhidmatan yang dihalakan melalui hos, kerana paket itu dihalakan sebagai trafik yang dihalakan ke hadapan dan tidak pernah membawa sumber tempatan hos dengan cara yang sama. Reka bentuk sedemikian biasanya memerlukan tanda yang ditetapkan semasa masuk dan peraturan yang sepadan dengan tanda itu.

Ia juga tidak menjadikan alamat awam hos muncul pada antara muka. Apabila NAT di hulu memiliki alamat itu, balasan masih mesti keluar melalui laluan yang NAT itu jangkakan, sebab itulah jadual WAN mesti mencerminkan get laluan dan awalan asal dan bukan julat awam yang diagak.

Kekalkan pengecualian itu didokumenkan dengan nombor jadual, keutamaan peraturan dan alamat sumber yang tepat. Perubahan seterusnya pada VPN atau antara muka boleh memecahkannya secara senyap, dan nota yang menamakan tiga nilai itu lebih cepat diperiksa daripada menemui semula simptom daripada laporan pelanggan.

Jika perkhidmatan masih membalas di laluan yang salah selepas carian yang dikelaskan mengikut sumber berjaya, bandingkan alamat sumber soket langsung dengan yang ada dalam peraturan. Perkhidmatan yang terikat pada alamat wildcard boleh memilih sumber berbeza daripada alamat yang anda uji, dan ketakpadanan itulah jurang yang tinggal.