Бір 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 оны жөндеу үшін қолданатын желіден қолжетімсіз.