VPN-ийн хамгаалалтын унтраалга дахин ачаалалтыг даван туулах уу? Хэрхэн шалгах

Дахин ачаалах нь хүмүүсийн хамгаалалтын унтраалгыг турших хамгийн түгээмэл арга бөгөөд хамгийн их худал хэлдэг шалгалт нь мөн. Клиент дэх чагтлах нүд нь зөвхөн тохиргоо; чухал нь сүлжээний стек өргөгдөх мөч ба туннель үнэхээр тогтох мөчийн хооронд ямар нэг зүйл блоклолыг хэрэгжүүлж байгаа эсэх юм. Windows дээр тэр зүйл ихэвчлэн Windows Filtering Platform дахь шүүлтүүр, Linux дээр нэгж ачаалдаг дүрмийн багц, macOS дээр pf зангуу, Android дээр системийн өөрийн байнга-асаалттай ба түгжээний тугнууд байдаг. Эдгээр зохицуулалт дахин ачаалалтын туршид маш өөрөөр ажилладаг бөгөөд зөвхөн платформын түвшний зүйл л хэн нэгэн нэвтрэхээс өмнө байрандаа байдаг.

Дахин ачаалалт гурван тусдаа асуулт тавьдаг

Асуултыг хуваа. Нэгд, бодлого диск дээр ачаалах үед ямар нэг зүйл уншдаг хэлбэрээр байгаа юу? Хоёрт, тэр уншигч ямар ч урсгал гарч чадахаас өмнө ажилладаг уу? Гуравт, бодлого таны анхаардаг урсгалыг буюу процесс бүр, хоёр хаягийн гэр бүл, DNS-ийг хамарч байна уу? Эхнийх нь тийм, хоёр дахь нь үгүй гэвэл хүмүүсийн дахин ачаалалтаас хойш үлддэггүй хамгаалалтын унтраалга гэж мэдээлдэг яг тэр гэмтэл үүснэ: эхлэх үед урсгал хэдэн секунд зугтаж, хэн нэгэн шалгахаар явах хүртэл хэн ч анзаардаггүй.

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

Блоклолыг сэргээдэг объектыг ол

Linux дээр netfilter дүрмүүд цөмд амьдардаг. Та зохицуулаагүй бол ачаалах үед юу ч тэдгээрийг буцааж бичдэггүй: iptables-save нэмэх netfilter-persistent, nftables.service ачаалдаг /etc/nftables.conf, эсвэл өөрийн скриптийг гүйцэтгэдэг systemd нэгж. Юу идэвхтэй байгааг шалга, өөрөө тохируулсан гэж санаж байгаа зүйлээ биш.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Хоёр дахь команд нь wfpstate.xml-г одоогийн хавтас руу бичнэ. Клиент холбогдохын өмнө аль хэдийн байгаа блоклох үйлдэлтэй шүүлтүүрүүдийг хай. Base Filtering Engine ачаалалтын эрт үед эхэлж, байнгын тугтайгаар нэмсэн шүүлтүүрүүдийг сэргээдэг, тиймээс зарим хамгаалалтын унтраалга клиентийн цонх үүсэхээс өмнө урсгалыг блоклодог, зарим нь блоклодоггүй. macOS дээр sudo pfctl -s info pf идэвхтэй эсэхийг мэдээлнэ, sudo pfctl -s rules юу ачаалагдсаныг харуулна, VPN клиентүүд ихэвчлэн дүрмээ үндсэн багц руу биш, зангуу руу холбодог. utun3-г нэрлэсэн дүрэм дараагийн ачаалалтын дараа өөр интерфэйс рүү зааж болно, учир нь тэр дугаар ажиллах үед олгогддог.

Сүлжээ өргөгдөх ба туннель өргөгдөх хоорондын зайг ажигла

Аюултай интервал нь бүхэл дахин ачаалалт биш, харин зай юм. Интерфэйс нэг мөчид түрээс болон анхдагч маршрут авдаг, VPN үйлчилгээ өөр мөчид эхэлдэг, туннель бүр ч хожуу баталгаажуулдаг, заримдаа хэрэглэгч нэвтэрч итгэмжлэлийн агент ажилласны дараа л. Блоклолыг хамгийн сүүлд хэрэгжүүлбэл зай дахь бүх зүйл ил гарч гадна гарна.

systemd хост дээр таамаглахын оронд дарааллыг унш. VPN болон галт хананы нэгжүүд дээр systemctl cat-г ажиллуулж, After= болон Before=-ийн хувьд network-pre.target эсвэл network-online.target хэрхэн байгааг хар. network-online.target-ийн дараа эрэмбэлэгдсэн галт хананы нэгж интерфэйст ялагдана; network-pre.target-ийг шаардаж, түүнээс өмнө эрэмбэлэгдсэн нэгж ялна. Windows дээр тэнцүү асуултууд нь үйлчилгээний эхлэх төрөл ба түүний хамаарал юм, учир нь Manual-д тавьсан үйлчилгээ ачаалалтын үеийн процессыг блоклож чадахгүй. Хэрэв таны шаардлага нэвтрэхээс өмнөх урсгалыг хамардаг бол зөвхөн төхөөрөмжийн түвшний зохицуулалт л хангана: Always On VPN төхөөрөмжийн туннель машины гэрчилгээгээр баталгаажиж, хэрэглэгч нэвтрэхээс өмнө холбогддог бөгөөд Microsoft төхөөрөмжийн туннелийн тохиргоог баримтжуулдаг хэрэглэгчийн туннелээс тусдаа. Android өөр замыг сонгож, байнга-асаалттай VPN-ийг хэрэгжүүлж, түүнгүй холболтыг апп-ын процессоос биш, системээс блоклодог.

Шалгалтыг ажиллуулж, дараа нь хоёр цагийн шугамыг харьцуул

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

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

Буцах замаа эвдэхгүйгээр зайг хаа

Ачаалалтын үед блоклол байхгүй бол хоёр дахь клиентийн дүрэм нэмэхийн оронд хэрэгжүүлэлтийг нэг давхарга доошлуул. Дүрмийн багцыг хадгалж, сүлжээ ашиглах боломжтой болохоос өмнө эрэмбэлэгдсэн нэгжээс ачаал, мөн тэр нэгжид өөрөө хамгаалах ёстой DNS асуулга эсвэл сүлжээний холболт шаардлагагүй гэдгийг батал. Хамрах хүрээ нь цаг хугацаатай адил чухал: хэрэглэгчийн ID эсвэл cgroup-той тохирох дүрмүүд системийн демон бүрийг блоклолын гадна үлдээдэг, зөвхөн IPv4-ийг боловсруулдаг багц IPv6 болон DNS-ийг хүртээмжтэй үлдээдэг.

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

Энэ зохицуулалтад итгэхээс өмнө дөрвөн зүйлийг дарааллаар нь батал. Бодлого нь ачаалалт уншдаг газарт хадгалагдсан. Тэр уншигч интерфэйс ашиглах боломжтой болохоос өмнө ажилладаг. Блоклол нь хоёр хаягийн гэр бүл болон DNS-ийг хамардаг. Блоклол идэвхтэй байхад VPN баталгаажуулж чадна. Дөрөв нь биелбэл дахин ачаалалт юу ч өөрчлөхгүй.