VPN-ийн NAT UFW-ийн before.rules файлд хаана байх ба түүнийг хэрхэн шалгах
before.rules доторх NAT мөр COMMIT бүхий хүчинтэй хүснэгтийн хэсгийн дотор байх ёстой. UFW-г дахин ачаалахын өмнө нэр дэвшигчийг iptables-restore --test-ээр задлан шинжилнэ үү.
Shell-д бичихэд ажилладаг NAT дүрэм before.rules файлд буулгахад бүтэлгүйтдэг, учир нь тэр файл скрипт биш. Энэ нь хүснэгтийн хэсгүүд, гинжин хэлхээний зарлалууд, хүснэгт бүрийн COMMIT тэмдэг бүхий сэргээх форматын баримт бичиг юм. Буруу газар байх мөр нь бүх сэргээлтийг таслах эсвэл байгаа гэж та бодсон дүрмүүдийг чимээгүй хаях болно. Доорх заавар нь хэсгийг хүрээ таамаглаж буй газарт байрлуулж, дараагийн дахин ачааллаас өмнө үр дүнг нотолно.
Shell команд нь сэргээх файл биш
iptables -t nat гэж эхлэх мөр нь iptables хоёртын файлд өгөх заавар, харин UFW-ийн уншдаг файл бүрэн дүрмийн багцын тайлбар юм. Ялгаа нь гадаад төрх биш: сэргээх формат аль хүснэгтэд байгаа, ямар гинжнүүд байгаа, хүснэгт хаана дуусахыг мэдэх ёстой. Тэр баримтад буулгасан команд нь синтаксийн алдаа эсвэл, бүр муугаар бол буруу хүснэгтэд хавсарсан дүрэм байна. Хүрээ эдгээр файлуудыг сэргээх хэрэгслээр ачаалдаг шалтгаан нь тэдгээр нь дараалсан бус, зарлалын шинжтэй.
Баримт бүтнээрээ ч ачаалагддаг тул нэг алдаатай хэсэг үлдсэн файлын хэрэглээг зогсоож болно. Тиймээс NAT хэсэг дэх жижиг алдаа шүүлтүүрийн дүрмийг хамт унагаж, ингэснээр галт хананы өөрчлөлт тасалдал болдог.
Хэсгийг байгаа хүснэгтийн хэсгийн дотор байрлуул
NAT хэсэг нь хэлбэртэй бөгөөд хэлбэр нь доторх дүрмийн текстээс илүү чухал. Хүснэгтийн толгой хэсгийг нээж, гинжин зарлалууд тоолуурыг тогтоож, дүрмүүд дараалан орж, COMMIT хэсгийг хаана.
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT
Дээрх пул ба интерфейс нь таны утгуудын орлуулагч; хуулбарлах үнэ цэнэтэй хэсэг нь бүтэц юм. Хэрэв файлд *nat хэсэг аль хэдийн байвал хоёр дахьыг нээхийн оронд тэр хэсгийн дотор дүрмийг нэмнэ үү, учир нь формат хүснэгт бүрт нэг COMMIT хүлээж, нэг хүснэгтийн хоёр хэсэг нь болохыг хүлээж буй засвар юм. Түгээлтийн гинжин тодорхойлолтыг хөндөхгүй хадгал, нийлүүлэгч өөрийн интеграцийн төлөө нэмсэн зүйлсийг оруулаад. UFW хүрээний гарын авлага before, user, after файлууд болон тохирох COMMIT-ийн шаардлагыг баримтжуулна.
Хэрэв файл хоосон бол түүнийг заавраас бүү дүүргэ. Аль багц үүнийг эзэмшиж байгаа, бодит ажиллаж буй бодлого юу болохыг тогтоо, учир нь хоосон байнгын файл цөмд дүрэм байхгүй гэдгийг нотлохгүй, ачаалсан дүрмийн багц дараагийн дахин ачаалалд бүрэн файл байхыг нотлохгүй. Эхлээд дэмжигдсэн суурь шугамыг сэргээж, дараа нь сайтын өөрчлөлтийг түүн дээр дахин хэрэглэ.
Нэр дэвшигчийг хэрэглэхгүйгээр шалга
Сэргээх хэрэгсэл дүрмийн багцыг хэрэглэхгүйгээр задлан шинжилж, бүтээж чадна, энэ нь боломжтой хамгийн хямд шалгалт юм. Үүнийг ажиллаж буй файлд биш, хамгаалагдсан хуулбар дээр ажиллуулж, гарах төлөв биш алдааны текстийг унш. Задлан шинжилгээний алдаа мөр, ихэвчлэн хүснэгтийг нэрлэдэг бөгөөд энэ нь бүтэлгүйтсэн дахин ачааллаас илүү мэдээлэл өгнө.
sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"
Тэр шалгалтыг давах нь баримт задлан шинжилэгдэж байгааг нотлох бөгөөд өөр юу ч биш. Энэ нь нэр дэвшигч UFW-ийн хамааралтай бүх гинжийг агуулж байгаа, зөвхөн таны зорьсон эх сурвалжид зөвшөөрөл өгч байгаа, эсвэл алсын удирдлага хүртээмжтэй хэвээр байгааг нотлохгүй. Эдгээр нь тусдаа хяналтууд бөгөөд сүүлийнх нь эхлэхээс өмнө нээгдэх хоёр дахь чуулганыг хүртэх ёстой.
Суулгасан backend болон хаягийн гэр бүлд тохирох хэрэгслийг сонго. nft backend-ийг нийцлийн давхаргаар ажиллуулж буй хостод тохирох команд хэрэгтэй, IPv6 дүрмүүд огт өөр файлд амьдардаг.
Дамжуулалт, NAT, хандалтын бодлогыг тусад нь барь
Эх сурвалжийн орчуулга нь хаяглалтын асуудлыг шийдэж, юу ч өгөхгүй. Дамжуулалт нь sysctl болон шүүлтүүрийн хүснэгтээр удирдуулдаг тусдаа зөвшөөрөл бөгөөд хонгил чиглүүлдэг ч урсгал дамжуулдаггүй үед хүмүүсийн мартдаг зүйл нь энэ юм. Хандалтын бодлого нь ямар эх сурвалж ямар үйлчилгээнд хүрч болох тухай гурав дахь шийдвэр бөгөөд ямар ч NAT дүрэм үүнийг илэрхийлдэггүй. Эдгээр гурвыг тусад нь байлгах нь алдааг нэг бүдэг шинж тэмдгийн оронд оношилгох боломжтой болгодог.
sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD
Эдгээр гурван гаралтыг нэг нэгээр биш, хамт унш. Дамжуулалт унтарсан masquerade дүрэм холбогддог ч хаана ч хүрдэггүй клиент үүсгэдэг бөгөөд энэ нь клиентийн талаас яг чиглүүлэлтийн гэмтэл мэт харагдаж, хүмүүсийг буруу файл руу илгээдэг. Шүүлтүүрийн хүснэгт нь хэт өргөн accept нуугдах газар бол, тэнд байхдаа түүний анхдагч бодлогыг шалга.
Дахин ачаалал, татгалзал, VPN алдагдлыг баталгаажуул
Гурван ажиглалт бүрэн хүлээн авах шалгалтыг бүрдүүлнэ: дахин ачаалал амжилттай, зөвшөөрөгдсөн клиентийн үйлдэл ажиллаж, татгалзах ёстой хүсэлт үнэхээр татгалзагдана. Гурав дахь нь алгасагддаг нь бөгөөд бодлого ер нь ямар нэг зүйл хийж байгаагийн цорын ганц нотолгоо юм.
sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v
Дараа нь таны зохиосон алдааг шалга. Хонгилыг унагаж, хост юу хийхийг ажигла, учир нь зөвхөн VPN асаалттай үед ажилладаг бодлого бол зарлаагүй хамааралтай бодлого юм. Дараа нь дахин нэг удаа ачаалж, ажиллах үр дүнг үлдэгдэл ажиллагааны төлөв биш, файл өгдөг гэдгийг нотол.
IPv4-ийн NAT нь IPv6-ийн талаар юу ч хэлдэггүй тул дүрэмтэй хамт тэр тэмдэглэлд хоёр гэр бүлийн төлөвлөсөн хамрах хүрээг бич. Зорилго нь уялдаатай удирдлагатай бодлого бөгөөд санамсаргүйгээр задлан шинжилэгдсэн хэсэг нь түүний нотолгоо биш.