Роутер VPN-ээр нэг төхөөрөмжийг нэвтрүүлэхэд унтраалга биш, гурван дүрэм хэрэгтэй

Роутер VPN дээр төхөөрөмж бүрийн унтраалга гэж байхгүй; таны хайж буй унтраалга бол таны өмнөөс бодлогын маршрутлалтын дүрэм бичдэг товчлол юм. Нэг зөөврийн компьютер, нэг портын хүрээ, нэг хаягийн жагсаалт эсвэл нэг LAN сегмент туннелийг ашиглах ёстой, бусад бүхэн WAN дээр үлдэх ёстой тэр мөчид та боломжийг асаах биш, бодлогын маршрут бүтээж байна. Ажил гурван хөдөлгөөнт хэсэгтэй бөгөөд тус бүр өөр өөрөөр бүтэлгүйтдэг: маршрутгүй тэмдэглэсэн хүснэгт чимээгүй мэт харагдана, буруу хэлхээнд тавьсан тэмдэг юу ч болоогүй мэт харагдана, дутуу NAT дүрэм холбогддог ч юу ч зөөдөггүй туннель мэт харагдана. Дахин хоёр хэсэг mangle дүрэмд хэзээ ч гарч ирдэггүйгээс алга болдог бөгөөд тэдгээр нь DNS ба IPv6 юм.

Домог: туннель бол клиентийн тохиргоо

Роутерын талын VPN клиент нэг бүдүүлэг зүйлийг сайн хийдэг: 0.0.0.0/0-ийг үндсэн маршрутлалтын хүснэгтэд хийгээд туннель рүү чиглүүлдэг. WireGuard үүнийг AllowedIPs-ээс гаргаж авдаг, OpenVPN серверээс түлхдэг redirect-gateway-ээс гаргаж авдаг бөгөөд хоёулаа роутерын ард байгаа хост бүрийн замыг өөрчилдөг. AllowedIPs-ийг нарийсгах эсвэл route-nopull нэмэх нь клиентийн суулгах зүйлийг өөрчилдөг. Энэ суулгалт хэнд хамаарахыг өөрчлөхгүй, учир нь клиент төхөөрөмжүүдийг хэзээ ч хардаггүй. Тэр зөвхөн пакетуудыг хардаг.

Эх үүсвэр эсвэл очих газраар сонгох нь маршрутлалтын шийдвэр тул роутерын бодлогын давхаргад хамаарна: RouterOS дээр mangle дүрэм ба хоёр дахь хүснэгт, OpenWrt эсвэл DD-WRT дээр MARK ба ip rule, эсвэл pfSense дээр гарц нь туннель болсон firewall дүрэм. Netgate-ийн WireGuard клиентийн жор таамаглахаас өмнө унших зүйл, учир нь тэр платформ дээр дүрмийн гарц, интерфэйсийн хуваарилалт, гарах NAT бичлэг бүгд нэг клиент туннелийг ашиглахаас өмнө санал нийлэх ёстой.

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

Эхний хэсэг: анхдагч маршрут биш туннель

RouterOS дээр клиентийг анхдагч маршрутгүйгээр нэмж, туннельд өөрийн хүснэгтийг өгнө. Эхний маршрут нь тэмдэглэсэн анхдагч; хоёр дахь нь бүтэлгүйтлийн хагас.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 нь 6.x-ийн хамт барьж байсныг салгадаг: хүснэгтийг /routing table add name=vpn fib-ээр зарлаж, дараа нь маршрут болон mangle дүрэмд нэрээр нь дурдана. Хүснэгтийг тодорхойлохгүйгээр routing-mark бичдэг 6.x хэсэг цэвэр ачаалагдаж, юутай ч таарахгүй. Өөр нэг сонгодог тохиолдол бол 0.0.0.0/1-ийн хоёр хагас, эсвэл нэг хүснэгтэд ижил зайд хоёр анхдагч: цөм нэгийг сонгож, дахин ачаалсны дараа зан төлөв өөрчлөгдөж болно.

Хоёр дахь хэсэг: маршрут хайхаас өмнө тэмдэглэ

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

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux firmware нь netfilter тэмдэг ба тэмдэглэсэн пакетуудыг таны дүүргэсэн хүснэгт рүү чиглүүлдэг дүрмээр ижил зүйлийг хийдэг:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Хэлхээ бол хэв маягийн сонголт биш. Пакет FORWARD-д хүрэх үед маршрутын хайлт аль хэдийн болсон байдаг тул тэнд MARK эсвэл DROP хийх нь зөвхөн дахин бичих эсвэл хаях боломжтой. Тэмдэг нь дамжуулагдсан урсгалд PREROUTING-д, роутер өөрөө үүсгэдэг урсгалд OUTPUT-д буух ёстой бөгөөд роутерын DNS, NTP, шинэчлэлтийн шалгалт тэнд амьдардаг. Тэр гаралтын зам нь бүрэн туннельдсэн тохиргоо гоожсон шалгалтад одоо ч ISP resolver-ээс хариулдаг нийтлэг шалтгаан юм.

Төхөөрөмжийн бодлогод гулсахгүй тохирол хэрэгтэй. Хаягийг DHCP-д нөөцөл, эсвэл тусгай сегментэд интерфэйсийг тааруул; дараа нь өөр төхөөрөмж рүү шилжих хаяг чимээгүйгээр буруу клиентэд туннелийг хэрэглэдэг. Өөрийн дэд сүлжээтэй SSID тус бүрийн гүүр нь ижил санааны илүү бат бөх хувилбар бөгөөд IPv6 дүрэмд ч байр өгдөг.

Гурав дахь хэсэг: NAT, DNS ба LAN-ын үл хамаарах зүйл

Туннелиар гарч буй урсгалд нөгөө тал хариулах эх хаяг хэрэгтэй. Хөрвүүлэлтийг туннелийн интерфэйсээр хязгаарла: RouterOS дээр out-interface=VPN_NAME, Linux дээр -o tun0, pfSense дээр тохирох гарах NAT бичлэг. Тэр хязгаарлалтгүй masquerade дүрэм таны орхихыг хүссэн урсгалыг ч дахин бичдэг, шинж тэмдэг нь туннельгүй төхөөрөмж нийтийн хаягаа алдах явдал.

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

DNS тусдаа замаар явдаг. Роутерын дамжуулдаг асуултууд роутерээс үүсэлтэй бөгөөд OUTPUT-ийг дагадаг, дамжуулсан тэмдгийг биш, тул бүрэн туннельдсэн зөөврийн компьютер ч ISP-ээр дамжуулан нэрийг шийдэж чадна. Клиентүүдийг туннелиар хүрэх resolver руу чиглүүл, эсвэл роутерын өөрийн port-53 урсгалыг тэмдэглэ, дараа нь хариулт вэб хүсэлттэй хамт аялсан гэж таамаглахгүйгээр шийдэгдсэн хаягийг шалга.

Дүрэм таарч байхад апп WAN-ыг ашигласаар байх үед

Очих газрын жагсаалтууд хурдан хуучирдаг. Нэр жагсаалтад байхгүй хаяг руу шийдэгддэг тул хүсэлт WAN руу явдаг, харин жагсаалтад байгаа хаяг руу хийсэн бүх шалгалт ажиллаж байсан. Жагсаалтыг клиентийн ашигладаг ижил resolver-ээс шинэчил, нэг төхөөрөмжөөс бүх урсгалыг үнэхээр хүсвэл эх үүсвэрт суурилсан сонгогчийг илүүд үз.

IPv6 бол чимээгүй тойролт юм. Төхөөрөмж өөрийн анхдагч маршрут, өөрийн дүрмийн багцтай хоёр дахь хаягийн гэр бүлтэй бөгөөд зөвхөн IPv4 хаягтай тааруулах нь бодлогын хагас юм. Ижил сонгогчийг ip6tables эсвэл nftables-ийн тэнцэлд хэрэглэ, эсвэл тэр сегментэд IPv6-г ослоор биш, санаатайгаар унтраа.

Тогтсон холболтууд ч чухал. Өөрчлөлтөөс өмнө үүссэн conntrack бичлэг хугацаа дуустал хуучин замыг дагадаг тул засварын үеэр нээлттэй байсан хөтөч хэзээ ч хэрэглэгдээгүй дүрэм шиг харагддаг. Бодлогыг үнэлэхээс өмнө шинэ холболт нээ, эсвэл төлөвийг цэвэрлэ.

Хоёр төхөөрөмж ба дахин ачааллаар шалга

Туннельд орох ёстой төхөөрөмж ба орох ёсгүй төхөөрөмжийг шалгаж, хурдны тоо биш хоёр дахь хопыг харьцуул. Тус бүрээс traceroute хоёр дахь хоп дээр туннелийн гарц эсвэл ISP-ийн гарцыг харуулдаг; хоёулаа ижил харагдвал тэмдэг эсвэл хүснэгт дүрмийн хэлснийг хийхгүй байна. Шалгалтад шинэ холболт ашигла.

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

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