Локал апп, VPN дүрэм: таны FORWARD гинжилт яагаад хэзээ ч ажиллахгүй вэ

Та VPN урсгалд зориулж FORWARD гинжилтэд дүрэм нэмж, мөн тэр Linux машинаас хүсэлтийг ажиллуулахад тоолуур тэг дээрээ үлддэг. Дүрэм магадгүй зөв байх. Пакет тэр замаар хэзээ ч явсангүй, учир нь машин дээр өөрөө үүссэн хүсэлтийг энэ нь дамжуулдаггүй. Пакетийн амьдралыг сокетоос утас хүртэл ажиглах нь яагаад ийм байгаа, дүрэм хаана байх ёстойг тайлбарлана.

Пакет хаана төрснийг ол

Netfilter-ийн дэгээний дараалал гурван тохиолдлыг ялгадаг бөгөөд зөвхөн нэг нь FORWARD-ыг хамарна:

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

Хоёр пакет, нэг түүх

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

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

Нэрийн огторгуй хил хязгаарыг зөөдөг

Контейнер зарчмыг өөрчлөхгүйгээр үүнийг хүндрүүлдэг. Аппын хүсэлт нь контейнерийн сүлжээний нэрийн огторгуйн доторх локал гаралт юм. Хост тэр урсгалыг виртуал Ethernet интерфейс дээр хүлээн авч дамжуулж болох тул хост дээрх FORWARD дүрэм утга учиртай байж болно, хүсэлт үүсгэсэн процесс хостын OUTPUT гинжилтэд хэзээ ч хүрээгүй байсан ч.

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

Тэмдэг ер нь хэрэгтэй юу гэж асуу

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

Маршрут илэрхийлж чадахгүй зүйлээс шийдвэр хамаарах үед ангилал хэрэгтэй, жишээ нь эх сурвалж, хэрэглэгч эсвэл процесс. Хүлээн авсан урсгалд PREROUTING дахь тэмдэглэгээ ажилладаг. Локал урсгалд тэмдэг тавьсны дараа шинэ маршрут хайлт эхлүүлж чадах гаралтын шатанд тэмдэглэх ёстой. nftables-д энэ нь гаралтын дэгээ дээрх route төрлийн гинжилт; энгийн гаралтын шүүлтүүрийн гинжилт утгыг тавиад маршрутыг өөрчлөхгүй орхино.

iptables-д ижил зүйл mangle OUTPUT зохион байгуулалтад амьдардаг бөгөөд мөн адил шаардлага үйлчилнэ: тэмдэг бий болсны дараа маршрутжуулалтын шийдвэрийг дахин харах ёстой. Дараа нь бодлогын дүрэм тэмдгийг хэрэглэж, ашиглах боломжтой маршрут агуулсан хүснэгт рүү заах ёстой. conntrack тэмдэг тавих нь гурав дахь, тусдаа үйлдэл; энэ нь урсгалд утга хадгалаад, тэр утгыг маршрутжуулалт уншиж чадахаар одоогийн пакет дээр өөрөө тавьдаггүй.

Хайлт ба тоолуурыг хамт шалга

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

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

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

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