tun0 байхгүй юу? nftables дахь тайлагдсан IPsec-ийг meta ipsec-ээр тохируулна уу

Та туннелийн интерфейс хүлээж, түүнийг хайж байгаа ч галт ханан дотор тохируулах зүйл байхгүй. Энэ нь бодлогод суурилсан гарц-ын хувьд хэвийн: шифрлэгдсэн солилцоо физик интерфейс дээр ирдэг бөгөөд дараа нь дамжуулагдах тайлагдсан дотоод пакет мөн ижил интерфейс дээр ирж байгаа мэт ажиглагддаг. tun0 байхгүй, учир нь үүнийг юу ч үүсгээгүй.

Дотоод хүсэлт нь өөрийн эх, очих газар, үйлчилгээтэй тусдаа пакет хэвээр байгаа бөгөөд цөм нь аль аюулгүй байдлын нэгдлээс гарсныг мэддэг. Яг энэ мэдлэгийг галт ханын дүрэм тохируулж чадна.

Хоёр пакет, нэг интерфейс

Орж буй чиглэлийг төсөөлөөрэй. ESP эсвэл UDP-д ороосон пакет ирж, цөм тохирох бодлогыг олж, тайлж, тодорхой пакетыг дамжуулах замд өгдөг. Зөвхөн интерфейсийн нэрийг хардаг дүрэм тэр пакетыг ижил утсаар ирж буй бусад урсгалаас ялгаж чадахгүй.

Түүнийг ялгаж буй зүйл бол пакетанд хавсарсан орж буй аюулгүй байдлын замын контекст юм. nftables үүнийг meta ipsec exists хэлбэрээр харуулдаг бөгөөд пакет IPsec аюулгүй байдлын замаар ирсэн үед энэ нь үнэн байна. Үүнийг клиентийн сан, очих газар, үйлчилгээтэй хослуулбал дүрэм аюулгүй байх хэмжээнд тодорхой болно.

Контекстийг орхих нь нийтлэг алдаа бөгөөд энэ нь гоёл чимэглэлийн бус, аюулгүй байдлын алдаа юм. Клиентийн сангаас ирсэн бүхнийг хүлээн авдаг дүрэм орон нутгийн сүлжээнээс ирсэн хуурамч пакетыг ч мөн адил дуртайяа хүлээн авна, учир нь эх хаяг нь өөрөө юу ч батлахгүй. Эхийг утга учиртай болгох хамгийн хямд арга бол аюулгүй байдлын замын контекст юм. Аудитын дараа нэмэхийн оронд дүрмийг эхнээс нь түүнтэй хамт бичээрэй.

Дамжуулах дүрмийг бичээрэй

10.90.0.0/24 дотор клиентүүдтэй баталгаажсан IPv4 алсын хандалтын үйлчилгээ, 203.0.113.40 дээр нэг зөвшөөрөгдсөн очих газар байна гэж үзье. Тэр урсгалын дүрмийн хэсэг ийм харагдана.

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

Хаягууд ба интерфейс нь солигдох жишээ юм. Хянагдсан эквивалентыг дамжуулах бодлогод урсгалыг өөрөөр татгалзах дүрмээс өмнө байрлуулж, суулгахын тулд одоо байгаа дүрмийн багцыг хоослох хэрэггүй; гарц бол цэвэр өрөөний туршилт биш.

oifname гэсэн нэр томьёог үлдээх нь зүйтэй. Энэ нь гарах шийдвэрийг баримтжуулж, дүрмийг таны санаанд ороогүй чиглэлд тохирохоос сэргийлдэг бөгөөд энэ нь интернет рүү хэд хэдэн замтай гарцад чухал юм. Нэг дээд сувагтай туршилтын хайрцагт нэр томьёо илүүдэл мэт санагдаж, хайрцаг хоёр дахь суваг авахаас өмнө түүнийг хасдаг нь яг ийм учраас юм.

Гадаад солилцооны зөвшөөрөл тусдаа. Гарцын оролтын замд түүний бодитоор ашигладаг IKE болон ESP эсвэл UDP боох портууд хэрэгтэй бөгөөд эдгээр зөвшөөрөл нь доторх тайлагдсан пакетын талаар юу ч зөвшөөрөхгүй. Хоёрыг хольсон тохиолдолд ажиллаж буй туннель бүхнийг дамжуулдаг галт ханатай хамт дуусдаг.

Орж буй контекст нь гарч буй контекст биш

Мөн тэр илэрхийллийн бүл нь эсрэг чиглэлийг rt ipsec-ээр хамардаг бөгөөд энэ нь пакетын ашиглах гарч буй аюулгүй байдлын нэгдлийг дүрсэлдэг. Энэ нь өөр асуултад хариулдаг: энэ пакет хаанаас ирсэн бэ гэдэг биш, харин дараагийн хэсэгт хамгаалагдах эсэх.

Энэ ялгаа нь нэг туннелийг дуусгаж нөгөө рүү дамжуулдаг гарцад чухал юм. Пакет тайлагдан ирсэн ч шифрлэгдэн гарах шаардлагатай байж болох бөгөөд зөвхөн орж буй контекстод зориулж бичсэн зөвшөөрөл гарч буй шаардлагын талаар юу ч хэлэхгүй. Хэрэв бодлого тэр хамгаалалтыг шаарддаг бол дүрмийн багц маршрутлалт шийднэ гэж таамаглахын оронд үүнийг илэрхийлэх ёстой.

Хоёр асуултыг тусдаа дүрэмд байлгаж, аль нь хэрэгжиж байгааг уншигч харна. Хоёуланг нь шалгадаг нэг ухаалаг дүрэм хянахад хэцүү, хагас нь тохирохоо болиход дибаг хийхэд хамаагүй хэцүү. Тоолууртай хоёр дүрэм аль шаардлага биелэхгүй байгааг ч хэлнэ, нэг нэгтгэсэн дүрэм үүнийг хэзээ ч хийхгүй.

NAT нь галт ханын шийдвэр биш

Хувийн клиентийн сангаас интернет рүү гарах урсгалд ихэвчлэн эх орчуулга хэрэгтэй бөгөөд ингэснээр хариу буцах замаа олно. Гэхдээ өөр гарч буй IPsec бодлогод сонгогдсон урсгал зайлшгүй шаардлагатай чөлөөлөлтөө хадгалах ёстой бөгөөд дараагийн хамгаалалтын шийдвэрийн талаар бодохгүйгээр хувийн эх бүрийг масклах нь үүнийг эвддэг.

NAT гинжин доторх зөвшөөрөл ч мөн ерөнхий зөвшөөрөл биш. NAT ба шүүлтүүр өөр өөр ажилтай бөгөөд NAT гинж тогтсон урсгалын дараагийн пакет бүрийг шалгадаггүй, яг ийм учраас аюулгүй байдлын үүднээс түүнд найдах нь туршилтад ажиллаж байгаа мэт харагдаад ачаалалд бүтэлгүйтдэг дүрмүүдийг бий болгодог.

Эсрэгээр нь ч үнэн бөгөөд хүмүүсийг гайхшруулдаг: нэг шүүлтүүрийн үндсэн гинжин дотор хаа нэгтээ байгаа зөвшөөрөл өөр нэг хэрэглэгдэх гинжин дэх дараагийн татгалзалтай харьцуулахад ямар ч жинтэй биш. Үр дүнг дэс дараалал ба гинжин хэмжээ шийддэг, файлд зөвшөөрөл байгаа эсэх биш.

Яг дотоод үйлчилгээг шалгана уу

Та зөвшөөрсөн тодорхой очих газар болон портыг бодит клиентээс туршиж, хариу буцаж ирж байгааг баталгаажуулна уу. Дараа нь зөвшөөрөөгүй зүйлийг туршиж, тэр нь дамждаггүйг шалгана уу, учир нь хэт өргөн дүрэм эхний туршилтыг зөв дүрэм шиг сайн дамждаг. Клиентээс хэзээ ч гарахгүй хүсэлт ч галт ханын үр дүн биш тул пакет ерөөсөн үнэлэгдсэн эсэхийг мэдэхийн тулд тоолууруудыг уншина уу. Хоёр туршилт ба нэг тоолуурын уншилт дүрмийн багцыг уншиж өнгөрүүлсэн бүтэн үдээс хойшлоос илүүг хэлнэ.

nftables-ийн лавлагаа нь meta ipsec, rt ipsec болон чиглэлд хамаарах илэрхийллүүдийг баримтжуулдаг бөгөөд суулгасан хувилбартай синтаксийг шалгах газар нь яг тэнд юм. Хамрах хүрээг тодорхой байлгаарай: энэ бол IPv4-ийн жишээ, IPv6-ийн талаар юу ч хэлэхгүй бөгөөд дур мэдэн нийтийн порт дамжуулалтыг VPN үйлчилгээний хэсэг болгохгүй.