tun0 yoxdur? nftables-də şifrəsi açılmış IPsec-i meta ipsec ilə uyğunlaşdırın

Bir tunel interfeysi gözləyirsiniz, onu axtarır və firewall-da uyğunlaşdıracaq heç nə tapmırsınız. Bu, siyasət əsaslı şlüz üçün normaldır: şifrələnmiş mübadilə fiziki interfeys üzərində gəlir və sonra ötürülən şifrəsi açılmış daxili paket də həmin interfeys üzərində gələn kimi müşahidə olunur. tun0 yoxdur, çünki onu heç nə yaratmayıb.

Daxili sorğu yenə də öz mənbəyi, təyinatı və xidməti olan ayrı bir paketdir və nüvə onun hansı təhlükəsizlik assosiasiyasından çıxdığını bilir. Firewall qaydasının uyğunlaşdıra biləcəyi şey məhz bu bilikdir.

İki paket, bir interfeys

Gələn istiqaməti təsəvvür edin. ESP və ya UDP ilə qablaşdırılmış paket gəlir, nüvə uyğun siyasəti tapır, onun şifrəsini açır və açıq paketi ötürmə yoluna verir. Yalnız interfeys adına baxan qayda həmin paketi eyni naqildə gələn hər hansı digər trafikdən ayıra bilməz.

Onu fərqləndirən paketə bağlanmış gələn təhlükəsizlik yolu kontekstidir. nftables bunu meta ipsec exists kimi təqdim edir və bu, paket IPsec təhlükəsizlik yolu ilə gəldikdə doğrudur. Onu müştəri hovuzu, təyinat və xidmətlə birləşdirin, qayda təhlükəsiz olacaq qədər dəqiqləşir.

Konteksti buraxmaq geniş yayılmış səhvdir və bu, kosmetik deyil, təhlükəsizlik səhvidir. Müştəri hovuzundan gələn hər şeyi qəbul edən qayda yerli şəbəkədən gələn saxta paketi də eyni məmnuniyyətlə qəbul edir, çünki mənbə ünvanı təkbaşına heç nəyin sübutu deyil. Mənbəyi mənalı etməyin ən ucuz yolu təhlükəsizlik yolu kontekstidir. Qaydanı auditdən sonra əlavə etmək əvəzinə əvvəldən onunla yazın.

Ötürmə qaydasını yazın

Tutaq ki, 10.90.0.0/24 daxilində müştəriləri olan autentifikasiyalı IPv4 uzaqdan giriş xidməti və 203.0.113.40 ünvanında bir təsdiqlənmiş təyinat var. Həmin axın üçün qayda fraqmenti belə görünür.

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

Ünvanlar və interfeys dəyişdirilməli nümunələrdir. Nəzərdən keçirilmiş ekvivalenti ötürmə siyasətinə, axını əks halda rədd edəcək qaydadan əvvəl yerləşdirin və onu quraşdırmaq üçün mövcud qaydalar dəstini təmizləməyin; şlüz təmiz otaq təcrübəsi deyil.

oifname termini saxlanmağa dəyər. O, çıxış qərarını sənədləşdirir və qaydanın nəzərdə tutmadığınız istiqamətdə uyğunlaşmasının qarşısını alır, bu da internetə bir neçə yolu olan şlüzdə vacibdir. Tək yuxarı kanallı sınaq qutusunda termin artıq görünür və məhz buna görə qutu ikinci yuxarı kanal qazanmazdan əvvəl atılır.

Xarici mübadilə üçün icazələr ayrıdır. Şlüzün giriş yolu həqiqətən istifadə etdiyi IKE və ESP və ya UDP qablaşdırma portlarını tələb edir və bu icazələr içəridəki şifrəsi açılmış paket barədə heç nəyə icazə vermir. İkisini qarışdırmaq, işləyən tunelin hər şeyi ötürən firewall ilə bitməsinin yoludur.

Gələn kontekst çıxan kontekst deyil

Eyni ifadə ailəsi digər istiqaməti rt ipsec ilə əhatə edir və bu, paketin istifadə edəcəyi çıxan təhlükəsizlik assosiasiyasını təsvir edir. O, fərqli suala cavab verir: bu paketin haradan gəldiyinə deyil, növbəti ayağında qorunub-qorunmayacağına.

Bu fərq həm bir tuneli sonlandıran, həm də digərinə ötürən şlüzdə vacibdir. Paket şifrəsi açılmış halda gəlib yenə də şifrələnmiş halda çıxmalı ola bilər və yalnız gələn kontekst üçün yazılmış qəbul çıxan tələb barədə heç nə demir. Əgər siyasət bu qorumamı tələb edirsə, qaydalar dəsti marşrutlaşdırmanın bunu həll edəcəyini fərz etmək əvəzinə bunu ifadə etməlidir.

İki sualı ayrı qaydalarda saxlayın ki, oxucu hansının tətbiq olunduğunu görsün. İkisini də yoxlayan tək ağıllı qayda nəzərdən keçirməkdə çətindir və bir yarısı uyğunlaşmağı dayandırdıqda sazlamaq daha da çətindir. Sayğaclı iki qayda həm də hansı tələbin uğursuz olduğunu deyir, birləşdirilmiş tək qayda isə bunu heç vaxt etməyəcək.

NAT firewall qərarı deyil

Şəxsi müştəri hovuzundan internetə gedən trafik adətən mənbə çevrilməsinə ehtiyac duyur ki, cavab geri yolunu tapsın. Lakin başqa çıxan IPsec siyasəti üçün seçilmiş trafik tələb olunan azadolmasını saxlamalıdır və növbəti qoruma qərarını düşünmədən hər şəxsi mənbəni maskalamaq bunu pozur.

NAT zənciri daxilində qəbul da ümumi icazə deyil. NAT və filtrləmənin işləri fərqlidir və NAT zənciri qurulmuş axının hər sonrakı paketini yoxlamır, buna görə də təhlükəsizlik üçün ona güvənmək sınaqda işləyən, yük altında uğursuz olan qaydalar yaradır.

Əksi də doğrudur və insanları çaşdırır: bir filtr əsas zəncirində hər hansı yerdə qəbul, başqa tətbiq olunan zəncirdəki sonrakı rədd qarşısında heç bir çəki daşımır. Nəticəni sıra və zəncir əhatəsi həll edir, faylda qəbulun olması deyil.

Dəqiq daxili xidməti yoxlayın

İcazə verdiyiniz konkret təyinatı və portu real müştəridən sınayın və cavabın qayıtdığını təsdiqləyin. Sonra icazə vermədiyiniz bir şeyi sınayın və keçmədiyini yoxlayın, çünki həddindən artıq geniş qayda ilk sınaqdan düzgün qayda qədər yaxşı keçir. Müştərini heç tərk etməyən sorğu da firewall nəticəsi deyil, ona görə paketin ümumiyyətlə qiymətləndirilib-qiymətləndirilmədiyini görmək üçün sayğacları oxuyun. İki sınaq və bir sayğac oxunuşu sizə qaydalar dəstini oxumaqla keçən bir günorta saatından çoxunu deyəcək.

nftables sənədləri meta ipsec və rt ipsec ifadələrini, həmçinin istiqamətə xas ifadələri sənədləşdirir və quraşdırılmış versiyanızla sintaksisi yoxlamaq üçün yer məhz orasıdır. Əhatəni də açıq saxlayın: bu IPv4 nümunəsidir, IPv6 barədə heç nə demir və ixtiyari geniş port ötürməsini VPN xidmətinin bir hissəsinə çevirmir.