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 што го изгубил стандардниот маршрут е недостапен од мрежата што би ја користеле за негова поправка.

Поврзани статии