tun0 yo'qmi? nftables da shifri ochilgan IPsec ni meta ipsec bilan moslashtiring

Siz tunnel interfeysini kutasiz, uni izlaysiz, va xavfsizlik devorida moslashtiradigan hech narsa yo'q. Bu siyosatga asoslangan shlyuz uchun normal: shifrlangan almashinuv jismoniy interfeysga keladi va keyin uzatiladigan shifri ochilgan ichki paket ham o'sha interfeysga kelayotgani kuzatiladi. tun0 yo'q, chunki uni hech narsa yaratmagan.

Ichki so'rov hali ham o'z manbasi, manzili va xizmatiga ega alohida paket, va yadro u qaysi xavfsizlik assotsiatsiyasidan chiqqanini biladi. Aynan shu bilimni xavfsizlik devori qoidasi moslashtira oladi.

Ikki paket, bitta interfeys

Kiruvchi yo'nalishni tasavvur qiling. ESP yoki UDP bilan o'ralgan paket keladi, yadro mos keladigan siyosatni topadi, shifrini ochadi va ochiq paketni uzatish yo'liga beradi. Faqat interfeys nomiga qaraydigan qoida bu paketni o'sha simdan keladigan boshqa har qanday trafikdan ajrata olmaydi.

Uni ajratadigan narsa paketga bog'langan kiruvchi xavfsizlik yo'lining kontekstidir. nftables uni meta ipsec exists sifatida ko'rsatadi, bu paket IPsec xavfsizlik yo'li orqali kelganda to'g'ri. Uni mijozlar puli, manzil va xizmat bilan birlashtiring, qoida xavfsiz bo'lish uchun yetarlicha aniq bo'ladi.

Kontekstni tashlab ketish keng tarqalgan xato, va bu bezak emas, xavfsizlik xatosi. Mijozlar pulidan kelgan hamma narsani qabul qiladigan qoida mahalliy tarmoqdan kelgan soxta paketni ham xuddi shunday xushmuomalalik bilan qabul qiladi, chunki manba manzili o'z-o'zidan hech narsaga dalil emas. Xavfsizlik yo'li konteksti manbani mazmunli qilishning eng arzon usulidir. Qoidani boshidanoq u bilan yozing, auditdan keyin qo'shish o'rniga.

Uzatish qoidasini yozing

10.90.0.0/24 da mijozlari bo'lgan autentifikatsiyalangan IPv4 masofaviy kirish xizmati va 203.0.113.40 da bitta tasdiqlangan manzil bor deb faraz qiling. Bu oqim uchun qoida parchasi shunday ko'rinadi.

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

Manzillar va interfeys almashtiriladigan misollardir. Ko'rib chiqilgan ekvivalentni uzatish siyosatiga oqimni aks holda rad etadigan qoidadan oldin qo'ying va uni o'rnatish uchun mavjud qoidalar to'plamini tozalamang; shlyuz toza xona tajribasi emas.

oifname atamasini saqlashga arziydi. U chiqish qarorini hujjatlashtiradi va qoidaning siz nazarda tutmagan yo'nalishda mos kelishini oldini oladi, bu internetga bir nechta yo'li bor shlyuzda muhim. Bitta yuqori kanali sinov qutisida atama ortiqcha ko'rinadi va shuning uchun quti ikkinchi kanalni olishidan oldin u olib tashlanadi.

Tashqi almashinuv uchun ruxsatlar alohida. Shlyuzning kirish yo'liga u haqiqatda ishlatadigan IKE va ESP yoki UDP o'rash portlari kerak, va bu ruxsatlar ichkaridagi shifri ochilgan paket haqida hech narsaga ruxsat bermaydi. Ikkalasini aralashtirish ishlayotgan tunnelning hamma narsani uzatadigan xavfsizlik devori bilan tugashining yo'lidir.

Kiruvchi kontekst chiquvchi kontekst emas

Xuddi shu iboralar oilasi boshqa yo'nalishni rt ipsec bilan qamrab oladi, u paket ishlatadigan chiquvchi xavfsizlik assotsiatsiyasini tavsiflaydi. U boshqa savolga javob beradi: bu paket qayerdan kelgani emas, balki keyingi qismida himoyalangan bo'ladimi.

Bu farq bir tunnelni tugatib, boshqasiga uzatadigan shlyuzda muhim. Paket shifri ochilgan holda kelishi va baribir shifrlangan holda chiqishi kerak bo'lishi mumkin, va faqat kiruvchi kontekst uchun yozilgan ruxsat chiquvchi talab haqida hech narsa aytmaydi. Agar siyosat shu himoyani talab qilsa, qoidalar to'plami buni ifodalashi kerak, marshrutlash hal qiladi deb o'ylash o'rniga.

Ikki savolni alohida qoidalarda saqlang, o'quvchi qaysi biri qo'llanayotganini ko'rsin. Ikkalasini ham tekshiradigan bitta aqlli qoidani ko'rib chiqish qiyin va uning yarmi mos kelishni to'xtatganda disk raskadrovka qilish ancha qiyin. Hisoblagichli ikki qoida qaysi talab bajarilmayotganini ham aytadi, buni bitta birlashtirilgan qoida hech qachon qilmaydi.

NAT xavfsizlik devori qarori emas

Shaxsiy mijozlar pulidan internetga ketadigan trafik odatda manba tarjimasiga muhtoj, javob qaytish yo'lini topsin. Lekin boshqa chiquvchi IPsec siyosati uchun tanlangan trafik o'zining zarur istisnosini saqlashi kerak, va keyingi himoya qarori haqida o'ylamasdan har bir shaxsiy manbani maskalash buni buzadi.

NAT zanjiri ichidagi ruxsat ham umumiy ruxsat emas. NAT va filtrlashning ishlari boshqacha, va NAT zanjiri o'rnatilgan oqimning har bir keyingi paketini tekshirmaydi, va shuning uchun xavfsizlik uchun unga tayanish sinovda ishlaydigandek ko'rinadigan va yuk ostida muvaffaqiyatsiz bo'ladigan qoidalarni keltirib chiqaradi.

Buning aksi ham to'g'ri va odamlarni hayratda qoldiradi: bitta filtr asosiy zanjirida qayerdadir ruxsat boshqa qo'llaniladigan zanjirdagi keyingi rad etishga qarshi hech qanday vaznga ega emas. Natijani tartib va zanjir qamrovi hal qiladi, faylda ruxsat borligi emas.

Aniq ichki xizmatni tekshiring

Siz ruxsat bergan aniq manzil va portni haqiqiy mijozdan sinab ko'ring va javob qaytishini tasdiqlang. Keyin ruxsat bermagan narsani sinab ko'ring va u o'tmasligini tekshiring, chunki juda keng qoida ham birinchi sinovdan to'g'ri qoida kabi yaxshi o'tadi. Mijozdan hech qachon chiqmaydigan so'rov ham xavfsizlik devori natijasi emas, shuning uchun paket umuman baholanganini bilish uchun hisoblagichlarni o'qing. Ikki sinov va bitta hisoblagich o'qishi sizga qoidalar to'plamini o'qib o'tkazilgan butun tushdan keyindan ko'proq aytadi.

nftables ma'lumotnomasi meta ipsec, rt ipsec va yo'nalishga xos iboralarni hujjatlashtiradi, va sintaksisni o'rnatilgan versiyangiz bilan tekshiradigan joy aynan o'sha. Va qamrovni aniq tuting: bu IPv4 misoli, u IPv6 haqida hech narsa aytmaydi va o'zboshimchalik bilan ochiq portlarni uzatishni VPN xizmatining qismiga aylantirmaydi.