Pi дээрх hotspot хэрэглэгчид TUN VPN-ээр гэрийн LAN-д хүрэхгүй

Орон нутгийн Wi-Fi болон Ethernet хэрэглэгчид Pi-ийн hotspot-д холбогдож, түүний DHCP хүрээнээс хаяг авч, гомдолгүйгээр интернэт хуудсуудыг ачаалдаг. Дараа нь тэдгээр хэрэглэгчид гэрийн LAN дээр файл хуваалт эсвэл вэб интерфэйс нээхэд хугацаа дуусдаг бол Pi өөрөө тэр LAN-д туннелээр хүрдэг. Утасгүй давхаргад юу ч эвдэрээгүй. Дутагдаж байгаа зүйл бол маршрутлагдсан гэрээ: hotspot префиксийг TUN интерфэйс рүү зөөх ёстой бөгөөд гэрийн талд ямар нэгэн зүйл хариултыг тэнд хэрхэн буцааж илгээхийг мэдэх ёстой. Нэг пакет очиж ирэх замаа гүйцээхийн тулд хоёр тал хоёулаа байх ёстой.

Гурван өөр ажилтай гурван холболт

Linux Ethernet гүүр кадруудыг очих MAC хаягаар дамжуулдаг. OpenVPN TUN горимд IP пакетуудыг зөөдөг бөгөөд MAC давхарга огт байхгүй тул орон нутгийн гүүр нэмэх нь туннелийг порт гэж хэзээ ч бүртгэдэггүй. цөмийн TUN/TAP баримт бичиг энэ ялгааг тайлбарладаг: TAP төхөөрөмж Ethernet интерфэйс шиг харагддаг, TUN төхөөрөмж тийм биш. Хоёр орон нутгийн портыг гүүрдэж дараа нь маршрутладаг загвар нь интерфэйсийн нэр юу ч гэсэн маршрутизатор юм.

Энэ ялгаа нь эзэмшлийг шийддэг. Хэрэглэгчдийн дэд сүлжээ, тэдний анхдагч гарц, тэр хүрээний DHCP эрх нь Pi-ийн орон нутгийн төлөвлөгөөнд хамаарна. Гэрийн DHCP нэвтрүүлэг маршрутлагдсан туннелийг давахгүй бөгөөд ямар ч гүүрний тохиргоо үүнийг өөрчлөхгүй; хэрэглэгчдийг гэрийн DHCP сервер рүү чиглүүлэх нь өөрийн алдааны горимтой тусдаа, санаатай реле загвар юм.

Модемыг хэрэглэгчийн гүүрээс гадна байлгаарай. PPP холболт нь өөр шошготой Ethernet төхөөрөмж биш бөгөөд pppd-ийн баримтлагдсан анхдагч маршрутын логик IPCP хэлэлцээрийн дараа ажиллаж, тэр холбоос унах үед маршрутаа буцааж авдаг. DHCP загварыг хуулж, usb0 бүрийг ppp0 болгон нэрлэх нь гарц, метрик эсвэл амьдралын мөчлөгийн талаар юу ч нотлохгүй.

Ямар ч тохиргоог засахын өмнө префиксүүдийг сонгоорой

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Эхний сав нь оператор модемд өгсөн underlay хаяг; энэ нь хэрэглэгч рүү чиглэсэн аливаа төлөвлөгөөнөөс гадна байх ёстой. Хоёр дахь нь серверийн сонгосон туннелийн дэд сүлжээ, ихэвчлэн өөрийн хувийн /24 сүлжээ. Гурав дахь нь hotspot гүүр, дөрөв дэх нь таны хүрэхийг хүсч буй гэрийн префикс юм. Энэ явалтад hotspot 172.28.90.0/24 авч, гүүр 172.28.90.1 дээр байна, гэрийн үйлчилгээний LAN 192.168.77.0/24-ыг хадгалж, энэ нь хэрэглэгчийн маршрутизаторуудын авчирдаг 192.168.1.0/24 болон 10.0.0.0/24 анхдагч болон операторын 100.64.0.0/10 хүрээнээс зайлсхийдэг.

Hotspot-ийн DHCP хүрээнд зөвхөн гүүрний хаягийг гарц гэж зарлаж, өөр юу ч биш. Hotspot хэрэглэгчдэд хэзээ ч гарц болгон гэрийн хаяг бүү өг; тэдэнд тэр сегмент рүү холбоосын түвшний зам байхгүй.

Чиглэл бүрийг түүнийг эзэмшдэг талд нь маршрутлаарай

Pi-д туннелээр гэрийн префикс рүү маршрут хэрэгтэй. Сервер горим дахь серверүүд ихэвчлэн тэр маршрутыг түлхдэг тул эхлээд дамжуулалт асаалттай, цөм tun0-оос гэрийн хаягийг шийдэж байгаа эсэхийг баталгаажуулаарай.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Хэрэв ip route get одоо ч underlay интерфэйсийг мэдээлж байвал тэнд зогсоорой; замын цаашдын юу ч буруу хайлтыг засахгүй.

Гэрийн төхөөрөмжүүдэд 172.28.90.0/24 руу маршрут байхгүй тул тэдний хариулт анхдагч гарцыг дагаж маршрутизатор дээр үхдэг. Хоёр дэмжигдсэн засвар байна. Нэг бол гэрийн маршрутизатор дээр hotspot префиксийг VPN серверийн LAN хаяг руу чиглүүлэх статик маршрут нэмэх, эсвэл сервер өөрөө гарц болох үед хэрэглэгчийн префиксийг серверийн өөрийн маршрутлалтын хүснэгтэд бүртгэх. OpenVPN-ийн олон хэрэглэгчийн горимд хэрэглэгчид тусгай лавлах нь тэр холбоог зөөдөг: хэрэглэгчийн гэрчилгээний нийтлэг нэрээр нэрлэгдсэн файл, дотор нь iroute 172.28.90.0 255.255.255.0 болон түүнийг серверийн цөмд суулгах тохирох route мөр байна. Сервер дээр таамагласан цөмийн маршрут нь аль хэрэглэгч префиксийг эзэмшиж байгааг серверт хэлэхтэй ижил мэдэгдэл биш юм.

Үүнийг ажиллуулахын тулд гэрийн сүлжээний DHCP үйлчилгээг VPN сервер рүү бүү зөө. Бүхэл гэрийн анхдагч гарцыг солих нь нэг хувийн буцах маршрут нэмэхээс хамаагүй том өөрчлөлт бөгөөд DNS, хаягийн нөөц, шинэ түрээсийг үл тоомсорлодог бүх төхөөрөмжийг бүтэлгүйтэл рүү чирдэг.

Галт ханыг таамаглахгүйгээр дамжуулалтыг нээ

Дамжуулалт асаалттай байх нь пакетыг нэвтрүүлнэ гэсэн үг биш. Гүүрээс туннель рүү урсгал шүүлтүүрийн дүрмүүдэд хүрсээр байгаа бөгөөд анхдагч drop дамжуулалтын бодлого hotspot урсгалыг хаядаг бол Pi-ийн өөрийн урсгал үргэлжилдэг, энэ нь дээрх хуваагдсан шинж тэмдгийг яг үүсгэдэг.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

br0-аас tun0 хүртэлх зөвшөөрлийн дүрэм болон тохирох хариу чиглэл, мөн эх сурвалжийг дахин бичиж болох postrouting дүрмийг хай. Хэрэв гинжин бодлого drop бөгөөд ямар ч дүрэм тохирохгүй бол бодлогыг accept болгохын оронд нарийн зөвшөөрлүүдийг нэмж дахин туршина уу.

Орчуулга бол шаардлага биш, бодлогын сонголт. Гэрийн LAN руу чиглэсэн эх NAT нь hotspot хэрэглэгч бүрийг Pi-ийн туннелийн хаяг мэт харагдуулж, гэрийн логт хэрэглэгч тус бүрийн хуваарилалтыг алдаж, анхны эх сурвалжийг хүлээдэг үйлчилгээг эвддэг. NATгүй маршрутлал хэрэглэгчийн хаягыг харагдахуйц байлгадаг ч дээрх буцах маршрутаас хамаардаг. Нэгийг сонгоод DNS болон IPv6-д мөн адил хандаарай, учир нь эвдэрсэн IPv6 замын хажууд ажиллаж буй IPv4 зам хөтөч дээр хагас эвдэрсэн гэж уншигдснаар байна.

Очиж ирэх замыг шалгаад, дараа нь санаатайгаар эвдээрэй

Hotspot хэрэглэгчээс туршаарай, хэзээ ч Pi-ээс биш, учир нь Pi-ийн өөрийн урсгал урагш болон буцах замыг хоёуланг нь тойрдог. Нэг хэрэглэгч гэрийн үйлчилгээнд хүрэх гэж оролдох үед хоёр интерфэйсийг ажиглаарай.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

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

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

Hotspot хэрэглэгч гэрийн нэрийг шийдэж, TCP үйлчилгээ нээж, нэг модемын дахин холболтын турш сессийг амьд байлгаж чадсан үед л загварыг хүлээн зөвшөөр. Хэрэв програм хэрэглээнд гэрийн сегмент дээр Ethernet түвшний илрүүлэлт үнэхээр шаардлагатай бол орон нутгийн гүүрийг гүүрдсэн гэж тайлбарлаж нэвтрүүлэг хүлээхийн оронд дэмжигдсэн Layer 2 загварыг сонгоорой.