Нэг Pi дээр hostapd ба OpenVPN: анхдагч маршрут хэнийх вэ?

hostapd болон OpenVPN клиент нэг Pi-г хуваалцаж болно, хэрэв гүүр өөрийн анхдагч маршрутаа хадгалж, туннель өөрийн сервер рүү замаа хадгалбал. Командууд ба буцаалт.

Утаснууд хандалтын цэгт холбогдож, хаяг авч, дараа нь туннель өргөгдөнгүүт юунд ч хүрэхгүй болно. hostapd энэ үед ихэвчлэн эрүүл байдаг бөгөөд OpenVPN ч мөн адил; эвдэрдэг зүйл бол анхдагч маршрут бөгөөд энэ нь гүүр дээр хэзээ ч байгаагүй эсвэл туннель VPN сервер рүү замыг үлдээлгүйгээр түүнийг сольсон. Энэ гарын авлага тэр маршрутыг өөрийн байранд нь буцааж, үр дүнг Pi-ээс биш клиентээс нотолно. Алхам бүр буцаах боломжтой бөгөөд энд юу ч туннелийн тохиргоог өөрчлөхгүй, дотор нь ямар урсгал хүсэхээ мэдэх хүртэл.

Ямар нэгэн зүйлийг засахын өмнө интерфейсүүдийг бүртгэ

Танил зохион байгуулалт нь утасгүй радио болон утастай портыг br0 дотор байрлуулж, hostapd-г гүүрний эсрэг эхлүүлж, dnsmasq-аас түрээ олгож, OpenVPN клиент tun0 үүсгэдэг. Тэгвэл гурван тусдаа шаардлага нэг мэт харагдана: хандалтын цэгийн клиентүүдэд гарц болгон Pi хэрэгтэй, Pi-д сервертээ хүрэх интернетийн маршрут хэрэгтэй, гүүрэнд тэдгээр клиентүүдийн ашиглаж болох гарцын хаяг хэрэгтэй.

Өөрчлөхөөс өмнө одоогийн байдлыг уншина уу, учир нь эдгээр дөрвөн команд интерфейсийн асуудлыг маршрутын асуудлаас тусгаарладаг.

ip -br addr
ip route show
ip link show master br0
bridge link show

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

Гүүрэнд өөрт нь хамаарах анхдагч маршрут өг

Raspberry Pi OS интерфейсийн файл бичигдсэний дараа гүүр үүссэн тохиолдолд гүүрийг анхдагч маршрутгүй үлдээдэг. Блок нь /etc/dhcpcd.conf дотор байх ёстой бөгөөд Pi-г биш, дээд чиглүүлэгчийг нэрлэх ёстой.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Тэр жишээнд 192.168.50.1 нь одоо байгаа чиглүүлэгч, 192.168.50.2 нь ижил дэд сүлжээн дэх Pi-ийн гүүрний хаяг тул тоонуудыг хуулахын оронд өөрийн төлөвлөгөөгөө тавь. Гүүрний гишүүд ч чиглүүлэгч шаардаж болохгүй, эс тэгвээс Pi-д өрсөлдөх анхдагч маршрутууд үлдэж, тэдгээрийн ялагч нь зорилгоос биш, хэмжүүр, хугацаанаас хамаарна.

systemctl restart dhcpcd-ийн дараа ip route show default br0-г нэг удаа харуулах ёстой бөгөөд утастай портоос давхардал байх ёсгүй. Хүснэгтийг биш, хайлтыг баталгаажуул, учир нь хуучин бичлэг ялагч бичлэгийн хажууд сууж болно: ip -4 route get 203.0.113.10 br0-г нэрлэх ёстой. Тэр хаяг нь TEST-NET-3 баримтжуулалтын мужаас гаралтай тул үүнийг уншиж байх үед бодит сервертэй мөргөлдөх боломжгүй.

Туннелийг өөрийн сервер рүү замыг булаахыг зогсоо

redirect-gateway-г хүлээн авдаг OpenVPN клиент анхдагч маршрутыг аваад туннель рүү чиглүүлдэг. Энэ нь хандалтын цэгийн бүх клиент VPN ашиглах ёстой үед зөв, зөвхөн зарим очих газар ашиглах ёстой үед буруу. Ямар ч тохиолдолд Pi-ийн сервертэй өөрийн холболт нь өөрөө баригдаж буй туннелийн дотор явж болохгүй. OpenVPN анхдагчийг дахин чиглүүлэхдээ анхны гарцаар дамжуулан алс руу хост маршрут нэмдэг бөгөөд энэ нь тээврийг амьд байлгадаг зан төлөв юм; хэрэв тэр маршрут байхгүй бол туннель тогтсон даруйд нуран унана.

Тухайн тээврийн замыг холбогдохын өмнө болон дараа хурдан харьцуулах нь тэр арван секундэд үнэ цэнэтэй. ip -4 route get 203.0.113.10 хоёр төлөвт доод түвшний төхөөрөмжийг нэрлэх ёстой бөгөөд зөвхөн хэмжүүр өөрчлөгдөнө. Хэрэв туннель өргөгдсөний дараа tun0-г нэрлэвэл хост маршрут хэзээ ч суулгагдаагүй бөгөөд дараагийн дахин холболт бүтэлгүйтнэ.

Зөвхөн сонгосон префиксүүд туннелээр гарах ёстой бол route-nopull-г ашиглаж, хүссэн маршрутуудаа гараар нэмэх, эсвэл серверээс илүү нарийн багц илгээ. Тэр загварт гүүр анхдагч маршрутаа хадгалж, DNS дараагийн шийдвэр болно: dnsmasq-г гэрийн шийдвэрлэгч рүү дамжуулах нь тэнд үнэхээр амьдардаг нэрсэд л утга учиртай.

Дамжуулалт ба NAT-ийн асуудлыг шийд

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT дүрэм нь сервер хандалтын цэгийн префиксийг хүлээж авахгүй үед ажилладаг товчлол боловч үнэ нь алс талын бүртгэлд клиент бүр Pi-ийн туннелийн хаяг мэт харагдана. Префиксийг NAT-гүй чиглүүлэх нь хаягуудыг харагдахуйц байлгана ба гэрийн талд 192.168.50.0/24-ийн буцах маршрутаас хамаарна.

Сонголтыг галт ханын дүрмүүдийн хажууд бич, учир нь загварт үл үзэгдэх NAT дүрэм зургаан сарын дараа тайлбарлашгүй болно. IPv6-г ижил шийдвэрт байлга; эвдэрсэн IPv6 замтай зэрэгцэх ажиллаж буй IPv4 зам хөтөч дээр хагас эвдэрсэн хэвээр уншигдана.

Клиентээс баталгаажуулаад, дараа нь цэвэрхэн буцаа

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

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Дараа нь Pi-д өөрийн гарах зам байгаа эсэхийг батал: ip route get 203.0.113.10 доод түвшний төхөөрөмжийг нэрлэх ёстой, сервер ICMP зөвшөөрвөл ping -c 3 -I br0 203.0.113.10 хариулах ёстой. Эхний хоёр клиентийн алхам давж, гурав дахь нь бүтэлгүйтвэл алдаа нь дамжуулалт эсвэл NAT-д байна. Хоёр дахь алхам бүтэлгүйтвэл гүүр эсвэл DHCP хараахан бүрэн бус байна.

Буцаалт нь нэг файлын засвар ба хоёр команд: блокыг устга, dhcpcd-г дахин эхлүүл, анхдагч маршрутыг ip route replace default via 192.168.50.1 dev br0-өөр тодорхой соль. Үйлчилгээний цонх хаагдахаас өмнө үүнийг хий, дараа нь биш, учир нь анхдагч маршрутаа алдсан Pi-д засварлахад ашиглах сүлжээнээс хүрэх боломжгүй.

Холбоотой нийтлэлүүд