VPN өөрчлөлтийн дараа маршрутер әкімшілік хуудас яагаад хариу өгөхөө болих вэ

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

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

Туннель хэзээ ч удирдлагын зам байгаагүй

Дамжуулалт ба оролт нь тусдаа ажил. «Клиент туннелээр NAS-д хүрч чадах уу?» гэдэг нь маршрутерээр дамжих пакетийн тухай дамжуулалтын асуулт. «Маршрутерийн SSH портыг нээж чадах уу?» гэдэг нь маршрутер өөрт нь хаягласан пакетийн тухай оролтын асуулт. Дамжуулсан трафикт зориулж бичсэн зөвшөөрлийн дүрэм хоёр дахь асуултад юу ч хийдэггүй бөгөөд трафикийг төгс зөөдөг туннель ч таны админы сессийг татгалзах хамгийн түгээмэл шалтгаан нь энэ.

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

Эхний давхарга: маршрутерийн өөрийн хаяг руу зам байна уу?

Клиентээс эхэлж цөмөөс пакет хаашаа явахыг асуу. Linux дээр ip route get 10.6.0.1 сонгосон зам, гарах интерфэйс, эх хаягийг хэвлэнэ. Хэрэв үйлчилгээ үзүүлэгч рүү чиглэсэн өгөгдмөл замыг мэдээлбэл, пакет хэзээ ч туннельд орохгүй бөгөөд маршрутер дээрх ямар ч дүрэм үүнийг аварч чадахгүй.

Туннелийн тал асуултын өөрийн хувилбартай. WireGuard AllowedIPs-ийг крипто түлхүүрийн маршрутжуулалтын хүснэгт гэж үздэг: тал бүр дээр хамтрагч ямар эх хаяг ашиглаж болох, ямар чиглэл тэр хамтрагч руу илгээгдэхийг зарлана. Хэрэв клиентийн бичлэгт маршрутерийн туннелийн хаяг байхгүй бол клиентэд тийш зам байхгүй. Хэрэв тухайн клиентийн серверийн бичлэг клиентийн туннелийн хаягийг хамарч чадахгүй бол сервер ямар ч галт ханын дүрэм харахаас өмнө пакетийг хаяна.

Бодлогыг дибаг хийхээс өмнө хүрэхийг хүсч буй яг хаягаа баталгаажуул. Хуучирсан DNS бичлэг эсвэл өөрчлөлтөөс өмнөх кэшлэгдсэн хөршийн бичлэг таныг маршрутер хэзээ ч эзэмшээгүй хаяг руу хөтөлнө.

Хоёр дахь давхарга: оролтын бодлого, дамжуулалтын бодлого биш

Галт хана пакет ирэх интерфэйс дээр дүрмийг үнэлнэ. pfSense болон OPNsense дээр интерфэйсийн таб болон дүрмийн дараалал галт ханы өөрийн үйлчилгээнүүд рүү трафик зөвшөөрөгдсөн эсэхийг шийднэ; LAN клиентүүдийг интернэт рүү гаргах дүрэм нь туннелийн хамтрагчид вэб GUI нээхийг зөвшөөрөх дүрэм биш. firewall4 бүхий OpenWrt дээр бүс бүр оролтын бодлого агуулна, option input 'ACCEPT' эсвэл 'REJECT', оролт нь REJECT бүс дэх туннелийн интерфэйс удирдлагын холболтыг татгалзах боловч дамжуулалт зөвшөөрөгдсөн бол трафикийг үргэлжлүүлэн дамжуулна.

Шинэ зам ажиллахын тулд түгжээний эсрэг дүрмийг бүү унтраа. Тэр дүрэм муу дүрэм LAN удирдлагын хаягийг түгжихээс сэргийлдэг; энэ нь LAN дэд сүлжээг хамгаалдаг, таны дөнгөж үүсгэсэн туннелийн дэд сүлжээг биш. Администраторын эх сурвалжид нэг нарийн дүрэм нэмж, аюулгүйн торыг хэвээр үлдээ. pfSense-ийн админы нэвтрэх баримт бичиг эдгээр хяналтууд хаана байгааг тайлбарладаг.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Гурав дахь давхарга: тэр хаяг дээр ямар нэгэн зүйл сонсож байна уу?

Үйлчилгээ ажиллаж байсан ч зөвхөн нэг хаягт холбогдсон тул хүрэх боломжгүй байж болно. OpenWrt-ийн uhttpd /etc/config/uhttpd дотор тодорхой сонсголын бичлэг хадгалдаг, жишээ нь list listen_http '0.0.0.0:80'; зөвхөн LAN хаягт холбогддог бүтэц туннелийн хаяг дээр юу ч хүлээж авахгүй, сонсголын интерфэйсийн тохиргоо харуулдаг бүтээгдэхүүнүүд ч мөн адил ажиллана. Дээрх сонсголын командууд үүнд шууд хариулна.

Дараа нь татгалзалыг чимээгүй байдлаас ялга. nc -vz 10.6.0.1 443 татгалзсан холболт буцаавал пакет маршрутерт хүрсэн бөгөөд ямар нэгэн зүйл түүнийг татгалзсан, эсвэл хаалттай порт, эсвэл тодорхой татгалзах дүрэм. Хугацаа дуустал өлгөөтэй байх нь пакет хаягдсан эсвэл хэзээ ч маршрутлагдаагүй гэсэн үг. Энэ ялгаа нь дараагийн аль давхаргыг шалгахыг хэлж, таван секунд зарцуулна.

VPN интерфэйс бол хил, сэргээх зам биш

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

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

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

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

Бодлогод хүрэхээс өмнө буцах замаа бэлдэ

Эхний өөрчлөлтөөс өмнө дөрвөн зүйлийг бич: туннель үхвэл төхөөрөмжид хэрхэн хүрэх, жишээ нь цуваа консол, үйлчилгээ үзүүлэгчийн консол эсвэл LAN дахь машин; одоогийн тохиргоо хаана экспортлогддог; аль нэг дүрэм эсвэл замыг өөрчлөх гэж байгаа; мөн тэр зүйлийг яг хэрхэн буцааж авах. OpenWrt дээр sysupgrade -b /tmp/backup.tar.gz тохиргоог барьж авдаг бөгөөд засварууд uci commit хүртэл хүлээгдэж байдаг нь цаг тухайд нь анзаарвал хямд буцаалт өгдөг. pfSense тохиргооны түүх хөтөлдөг, AutoConfigBackup нь өмнө нь асаалттай байсан тохиолдолд л тусална. Хэрэв маршрутер fail-closed дүрмийн багц ажиллуулдаг бол төлөвлөсөн засварын зам тэр дүрэм блоколддог трафикийн дотор биш гэдгийг баталгаажуул, дахин ачаалах нь байнгын дүрмийг устгахын оронд дахин хэрэглэдэг гэдгийг сана.

Оролдлого бүрт нэг хил өөрчил, дараа нь нээлттэй үлдээсэн shell-ийн оронд шинэ холболтоос шалга. Шалгалт бүтэхгүй бол дараагийн давхаргад хүрэхээс өмнө тэр нэг өөрчлөлтийг буцаа. Туннель бүх хугацаанд дээгүүр байж болно, гэхдээ ногоон төлөвийн дүрс нь та одоо ч нэвтэрч чадна гэдгийг нотлохгүй.

Явахаас өмнөх хурдан шалгалт:

• Дөнгөж засварласан дүрмээс хамааралгүй эх сурвалжаас маршрутерт хүрч чадах уу?
• Туннелийн интерфэйс дээрх оролтын бодлого зөвхөн администраторын эх сурвалжид зөвшөөрөл өгдөг үү?
• Удирдлагын үйлчилгээ туннель дээр байгаа хаягт холбогдсон уу?
• Нэг татгалзсан хамтрагч, нэг шинэ сессийг шалгасан уу?
• WAN удирдлагын гадаргуу одоо ч хаалттай юу?