Tiada tun0? Padankan IPsec dinyahsulit dalam nftables dengan meta ipsec

Anda menjangkakan antara muka terowong, mencarinya, dan tiada apa untuk dipadankan dalam tembok api. Itu normal untuk gerbang berasaskan dasar: pertukaran disulitkan tiba pada antara muka fizikal, dan paket dalaman yang dinyahsulit yang kemudian dimajukan juga diperhatikan tiba pada antara muka yang sama. Tiada tun0 kerana tiada apa yang menciptanya.

Permintaan dalaman masih merupakan paket berasingan dengan sumber, destinasi dan perkhidmatannya sendiri, dan kernel tahu dari persatuan keselamatan mana ia keluar. Pengetahuan itulah yang boleh dipadankan oleh peraturan tembok api.

Dua paket, satu antara muka

Bayangkan arah masuk. Paket yang dikapsulkan ESP atau UDP tiba, kernel menemui dasar yang sepadan, menyahsulitnya dan menyerahkan paket jelas kepada laluan pemajuan. Peraturan yang hanya melihat nama antara muka tidak dapat membezakan paket itu daripada trafik lain yang tiba pada wayar yang sama.

Apa yang membezakannya ialah konteks laluan keselamatan masuk yang dilampirkan pada paket. nftables mendedahkannya sebagai meta ipsec exists, yang benar apabila paket tiba melalui laluan keselamatan IPsec. Gabungkannya dengan kumpulan klien, destinasi dan perkhidmatan, dan peraturan menjadi cukup khusus untuk selamat.

Meninggalkan konteks adalah kesilapan biasa, dan ia kesilapan keselamatan bukan kosmetik. Peraturan yang menerima apa sahaja yang berasal dari kumpulan klien turut menerima paket palsu dari rangkaian tempatan dengan senang hati, kerana alamat sumber bukan bukti apa-apa dengan sendirinya. Konteks laluan keselamatan ialah cara paling murah untuk menjadikan sumber bermakna. Tulis peraturan dengannya dari awal dan bukannya menambahnya selepas audit.

Tulis peraturan pemajuan

Andaikan perkhidmatan akses jauh IPv4 yang disahkan dengan klien dalam 10.90.0.0/24 dan satu destinasi diluluskan pada 203.0.113.40. Serpihan peraturan untuk aliran itu kelihatan seperti ini.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Alamat dan antara muka ialah contoh untuk diganti. Letakkan persamaan yang telah disemak dalam dasar pemajuan sebelum peraturan yang jika tidak akan menolak aliran itu, dan jangan kosongkan set peraturan sedia ada untuk memasangnya; gerbang bukan eksperimen bilik bersih.

Istilah oifname wajar dikekalkan. Ia mendokumenkan keputusan keluar dan menghalang peraturan daripada padan dalam arah yang tidak anda maksudkan, yang penting pada gerbang dengan beberapa laluan ke internet. Pada kotak ujian dengan satu pautan atas istilah itu kelihatan berlebihan, dan itulah sebabnya ia dibuang sebelum kotak itu mendapat pautan kedua.

Kebenaran untuk pertukaran luar adalah berasingan. Laluan input gerbang memerlukan port IKE dan ESP atau pengkapsulan UDP yang benar-benar digunakannya, dan kebenaran itu tidak membenarkan apa-apa mengenai paket yang dinyahsulit di dalam. Mencampurkan kedua-duanya ialah cara terowong yang berfungsi berakhir dengan tembok api yang memajukan segala-galanya.

Konteks masuk bukan konteks keluar

Keluarga ungkapan yang sama merangkumi arah lain dengan rt ipsec, yang menerangkan persatuan keselamatan keluar yang akan digunakan oleh paket. Ia menjawab soalan yang berbeza: bukan dari mana paket ini datang, tetapi sama ada ia akan dilindungi pada bahagian seterusnya.

Perbezaan itu penting pada gerbang yang serentak menamatkan satu terowong dan memajukan ke terowong lain. Paket boleh tiba dinyahsulit dan masih perlu keluar disulitkan, dan penerimaan yang ditulis hanya untuk konteks masuk tidak mengatakan apa-apa tentang keperluan keluar. Jika dasar memerlukan perlindungan itu, set peraturan harus menyatakannya dan bukannya menganggap penghalaan akan mengendalikannya.

Simpan kedua-dua soalan dalam peraturan berasingan supaya pembaca dapat melihat yang mana dikuatkuasakan. Satu peraturan pintar yang memeriksa kedua-duanya lebih sukar disemak dan jauh lebih sukar dinyahpepijat apabila separuhnya berhenti padan. Dua peraturan dengan pembilang juga memberitahu anda keperluan mana yang gagal, sesuatu yang tidak akan dilakukan oleh satu peraturan gabungan.

NAT bukan keputusan tembok api

Trafik ke internet dari kumpulan klien persendirian biasanya memerlukan terjemahan sumber supaya balasan menemui jalan pulang. Tetapi trafik yang dipilih untuk dasar IPsec keluar yang lain mesti mengekalkan pengecualian yang diperlukan, dan menyamarkan setiap sumber persendirian tanpa memikirkan keputusan perlindungan seterusnya memecahkan itu.

Penerimaan di dalam rantaian NAT juga bukan kebenaran umum. NAT dan penapisan mempunyai tugas berbeza, dan rantaian NAT tidak memeriksa setiap paket kemudian bagi aliran yang telah ditetapkan, dan itulah sebabnya bergantung padanya untuk keselamatan menghasilkan peraturan yang kelihatan berfungsi dalam ujian dan gagal di bawah beban.

Sebaliknya juga benar dan mengejutkan orang: penerimaan di suatu tempat dalam satu rantaian asas penapisan tidak mempunyai sebarang berat terhadap penolakan kemudian dalam rantaian lain yang terpakai. Urutan dan skop rantaian menentukan hasilnya, bukan kehadiran penerimaan dalam fail.

Sahkan perkhidmatan dalaman yang tepat

Uji destinasi dan port khusus yang anda benarkan, dari klien sebenar, dan sahkan bahawa balasan kembali. Kemudian uji sesuatu yang tidak anda benarkan dan sahkan bahawa ia tidak lulus, kerana peraturan yang terlalu luas lulus ujian pertama sama baiknya dengan yang betul. Permintaan yang tidak pernah meninggalkan klien juga bukan hasil tembok api, jadi baca pembilang untuk melihat sama ada paket itu dinilai langsung. Dua ujian dan satu bacaan pembilang akan memberitahu anda lebih daripada satu petang membaca set peraturan.

Rujukan nftables mendokumenkan meta ipsec, rt ipsec dan ungkapan khusus arah, dan di situlah tempat memeriksa sintaks terhadap versi yang anda pasang. Dan pastikan skop jelas: ini contoh IPv4, ia tidak mengatakan apa-apa tentang IPv6, dan ia tidak menjadikan pemajuan port awam sewenang-wenangnya sebagai bahagian perkhidmatan VPN.