hostapd и OpenVPN на једном Pi: чија је подразумевана рута?

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, па не може да се судари са правим сервером док ово читате.

Спречите тунел да отима пут до сопственог сервера

OpenVPN клијент који прихвата redirect-gateway преузима подразумевану руту и усмерава је у тунел. То је исправно када сваки клијент приступне тачке треба да користи 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 у истој одлуци; радни пут IPv4 поред поквареног пута IPv6 и даље се чита као напола покварен у прегледачу.

Проверите са клијента, затим се чисто вратите

Тестирајте овим редом са телефона или преносног рачунара на приступној тачки: закуп из 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 треба да именује уређај нижег слоја, а ping -c 3 -I br0 203.0.113.10 треба да одговори ако сервер дозвољава ICMP. Ако прва два корака клијента прођу, а трећи не успе, грешка је у прослеђивању или NAT-у. Ако други корак не успе, мост или DHCP још нису потпуни.

Враћање је једно уређивање датотеке и две команде: уклоните блок, поново покрените dhcpcd и замените подразумевану руту изричито са ip route replace default via 192.168.50.1 dev br0. Учините то пре него што се прозор за одржавање затвори, а не после, јер Pi који је изгубио подразумевану руту није доступан са мреже коју бисте користили да га поправите.

Повезани чланци