Бир Pi'де hostapd жана OpenVPN: демейки маршрут кимдики?

Телефондор кирүү чекитине туташат, дарек алышат, анан туннель көтөрүлгөндөн кийин эч нерсеге жете алышпайт. 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 үчүн кайтаруу маршрутуна көз каранды.

Тандоону firewall эрежелеринин жанына жазыңыз, анткени долбоордо көрүнбөгөн 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'ни оңдоо үчүн колдоно турган тармактан жетүү мүмкүн эмес.