hostapd и OpenVPN на един Raspberry Pi: кой притежава маршрута по подразбиране?

hostapd и клиент на OpenVPN могат да споделят един Raspberry Pi, когато мостът запази собствения си маршрут по подразбиране, а тунелът запази път до своя сървър. Команди и откат.

Телефоните се свързват с точката за достъп, получават адрес и след това не достигат до нищо, щом тунелът се вдигне. hostapd обикновено е в добро състояние в това положение, както и OpenVPN; това, което се чупи, е маршрутът по подразбиране, който или никога не е съществувал на моста, или е бил заменен от тунела, без да остави път до самия VPN сървър. Това ръководство връща този маршрут на мястото му и доказва резултата от клиент, а не от Raspberry Pi. Всяка стъпка е обратима и нищо тук не променя конфигурацията на тунела, докато не разберете кой трафик искате вътре в него.

Опишете интерфейсите, преди да редактирате каквото и да е

Познатата схема поставя безжичното радио и кабелния порт вътре в br0, стартира hostapd срещу моста и раздава наеми от dnsmasq, докато клиент на OpenVPN създава tun0. Тогава три отделни изисквания изглеждат като едно: клиентите на точката за достъп се нуждаят от Raspberry Pi като свой шлюз, Raspberry Pi се нуждае от маршрут към интернет, за да достигне сървъра си, а мостът се нуждае от адрес на шлюз, който тези клиенти да използват.

Прочетете текущото състояние, преди да го промените, защото тези четири команди отделят проблем с интерфейса от проблем с маршрутизацията.

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

Ако br0 има адрес, но няма маршрут по подразбиране, клиентите достигат до Raspberry Pi и до нищо след него. Ако маршрутът по подразбиране сочи към tun0, докато тунелът е спрян, Raspberry Pi няма никакъв работещ път и симптомът при клиента изглежда точно същият. И двата случая изглеждат еднакво от телефон, затова таблицата с маршрути трябва да се чете директно.

Дайте на моста маршрут по подразбиране, който му принадлежи

Raspberry Pi OS често оставя моста без маршрут по подразбиране, когато мостът е възникнал след записването на файла за интерфейса. Блокът принадлежи в /etc/dhcpcd.conf и трябва да посочва горния маршрутизатор, а не Raspberry 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 е адресът на моста на Raspberry Pi в същата подмрежа, затова заменете с вашия собствен план, вместо да копирате числата. Членовете на моста също не трябва да искат маршрутизатори, иначе Raspberry 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, и е грешно, когато трябва само някои дестинации. Както и да е, собствената връзка на Raspberry Pi към сървъра не трябва да минава вътре в тунела, който той все още изгражда. OpenVPN добавя маршрут към хоста през оригиналния шлюз, когато пренасочва маршрута по подразбиране, и това е точно поведението, което поддържа транспорта жив; ако този маршрут липсва, тунелът се срива веднага щом се установи.

Бързо сравнение на този транспортен път преди и след свързване си струва десетте секунди. ip -4 route get 203.0.113.10 трябва да посочи устройството от долния слой и в двете състояния, като се променя само метриката. Ако посочи tun0 след вдигане на тунела, маршрутът към хоста никога не е бил инсталиран и следващото повторно свързване ще се провали.

Когато само избрани префикси трябва да преминават през тунела, използвайте route-nopull и добавете желаните маршрути на ръка или изпратете по-тесен набор от сървъра. Мостът запазва маршрута по подразбиране в тази схема и DNS става следващото решение: препращането на dnsmasq към домашен резолвер има смисъл само за имената, които наистина живеят там.

Решете въпроса с препращането и NAT

Пълният тунел изисква включено препращане на Raspberry 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 е краткият път, който работи, когато сървърът не приеме префикса на точката за достъп, с цената всеки клиент да изглежда като тунелния адрес на Raspberry 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

След това потвърдете, че Raspberry 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. Направете това преди прозорецът за поддръжка да се затвори, а не след това, защото Raspberry Pi, който е загубил маршрута си по подразбиране, е недостъпен от мрежата, която бихте използвали, за да го поправите.

Подобни статии