hostapd és OpenVPN egy Pi-n: kié az alapértelmezett útvonal?

A telefonok csatlakoznak a hozzáférési ponthoz, címet kapnak, majd semmit sem érnek el, amint az alagút feljön. A hostapd ilyenkor általában egészséges, és a OpenVPN is; ami elromlik, az az alapértelmezett útvonal, amely vagy soha nem létezett a hídon, vagy az alagút lecserélte anélkül, hogy utat hagyott volna magához a VPN-kiszolgálóhoz. Ez az útmutató visszateszi az útvonalat a helyére, és az eredményt kliensről bizonyítja, nem a Pi-ről. Minden lépés visszafordítható, és itt semmi nem változtatja meg az alagút konfigurációját, amíg nem tudja, milyen forgalmat akar benne.

Leltározza fel az interfészeket, mielőtt bármit szerkeszt

Az ismert elrendezés a vezeték nélküli rádiót és a kábeles portot a br0 belsejébe teszi, a hostapd-t a híd ellen indítja, és bérleteket oszt a dnsmasq-ból, miközben egy OpenVPN-kliens létrehozza a tun0-t. Ekkor három külön követelmény egynek látszik: a hozzáférési pont klienseinek a Pi kell átjáróként, a Pi-nek útvonal kell az internetre, hogy elérje a szerverét, a hídnak pedig olyan átjárócím kell, amelyet ezek a kliensek használhatnak.

Olvassa el a jelenlegi állapotot, mielőtt megváltoztatja, mert ez a négy parancs elválasztja az interfészproblémát az útvonalproblémától.

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

Ha a br0 címet visel, de nincs alapértelmezett útvonala, a kliensek elérik a Pi-t és semmit azon túl. Ha az alapértelmezett útvonal a tun0-re mutat, miközben az alagút le van állva, a Pi-nek egyáltalán nincs működő útja, és a kliens tünete pontosan ugyanúgy néz ki. Mindkét eset azonosnak látszik telefonról, ezért az útvonaltáblát közvetlenül kell olvasni.

Adjon a hídnak egy alapértelmezett útvonalat, amely hozzá tartozik

A Raspberry Pi OS gyakran alapértelmezett útvonal nélkül hagyja a hidat, ha a híd az interfészfájl megírása után jött létre. A blokk a /etc/dhcpcd.conf fájlba tartozik, és a felsőbb routert kell megneveznie, nem a Pi-t.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Ebben a példában a 192.168.50.1 a meglévő router, a 192.168.50.2 pedig a Pi híd címe ugyanabban az alhálózatban, ezért a saját tervét illessze be a számok másolása helyett. A híd tagjai sem kérhetnek routereket, különben a Pi-n versengő alapértelmezett útvonalak maradnak, amelyek győztese a metrikától és az időzítéstől függ, nem a szándéktól.

A systemctl restart dhcpcd után a ip route show default-nek egyszer kell felsorolnia a br0-t, és a kábeles porttól nem lehet duplikátum. A keresést ellenőrizze, nem a táblát, mert egy elavult bejegyzés egy nyertes mellett ülhet: a ip -4 route get 203.0.113.10-nek a br0-t kell megneveznie. Ez a cím a TEST-NET-3 dokumentációs tartományból származik, így nem ütközhet valódi szerverrel, miközben ezt olvassa.

Akadályozza meg, hogy az alagút eltérítse a saját szerveréhez vezető utat

Az az OpenVPN-kliens, amely elfogadja a redirect-gateway-et, átveszi az alapértelmezett útvonalat, és az alagútba irányítja. Ez akkor helyes, ha minden hozzáférési pont kliensének a VPN-t kell használnia, és akkor helytelen, ha csak bizonyos céloknak kell. Bármelyik esetben a Pi saját kapcsolata a szerverrel nem utazhat abban az alagútban, amelyet még épít. Az OpenVPN gazdaútvonalat ad a távoli félhez az eredeti átjárón keresztül, amikor átirányítja az alapértelmezettet, és pontosan ez a viselkedés tartja életben a szállítást; ha ez az útvonal hiányzik, az alagút összeomlik, amint létrejön.

Ennek a szállítási útnak a gyors összehasonlítása csatlakozás előtt és után megéri azt a tíz másodpercet. A ip -4 route get 203.0.113.10-nek mindkét állapotban meg kell neveznie az alsó eszközt, csak a metrika változik. Ha az alagút feljövetele után a tun0-et nevezi meg, a gazdaútvonal soha nem települt, és a következő újracsatlakozás meghiúsul.

Amikor csak kiválasztott előtagoknak kell átkelniük az alagúton, használja a route-nopull-et, és adja hozzá kézzel a kívánt útvonalakat, vagy küldjön szűkebb készletet a szerverről. A híd ebben a felállásban megtartja az alapértelmezett útvonalat, és a DNS lesz a következő döntés: a dnsmasq továbbítása egy otthoni feloldóhoz csak azoknak a neveknek van értelme, amelyek valóban ott élnek.

Döntse el a továbbítás és a NAT kérdését

A teljes alagúthoz engedélyezett továbbítás kell a Pi-n, és egy túloldali átjáró, amely hajlandó a hozzáférési pont alhálózatát irányítani. A továbbítást mindenek előtt ellenőrizze, mert egy nulla minden útvonalváltoztatást jelentéktelenné tesz.

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

A NAT-szabály az a rövidítés, amely akkor működik, ha a szerver nem fogadja el a hozzáférési pont előtagját, azzal az áron, hogy minden kliens a Pi alagútcímeként jelenik meg a túloldali naplókban. Az előtag NAT nélküli irányítása láthatóvá tartja a címeket és a hazai oldalon a 192.168.50.0/24 visszaútvonalától függ.

Írja le a választ a tűzfalszabályok mellé, mert a tervezésben láthatatlan NAT-szabály hat hónap múlva megmagyarázhatatlanná válik. Tartsa az IPv6-ot ugyanabban a döntésben; egy működő IPv4-út egy törött IPv6-út mellett továbbra is félig töröttként olvasható a böngészőben.

Ellenőrizze kliensről, majd állítsa vissza tisztán

Tesztelje ebben a sorrendben egy telefonról vagy laptopról a hozzáférési ponton: bérlet a dnsmasq-ból, ping a híd címére, majd egy cél a túloldalon. Minden lépés egy réteget izolál, ahelyett hogy egyetlen haszontalan hibát produkálna.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Utána erősítse meg, hogy a Pi-nek még mindig van saját kifelé vezető útja: a ip route get 203.0.113.10-nek az alsó eszközt kell megneveznie, és a ping -c 3 -I br0 203.0.113.10-nek válaszolnia kell, ha a szerver engedi az ICMP-t. Ha az első két klienslépés átmegy és a harmadik meghiúsul, a hiba a továbbításban vagy a NAT-ban van. Ha a második lépés hiúsul meg, a híd vagy a DHCP még hiányos.

A visszaállítás egy fájlszerkesztés és két parancs: távolítsa el a blokkot, indítsa újra a dhcpcd-t, és cserélje ki az alapértelmezett útvonalat kifejezetten a ip route replace default via 192.168.50.1 dev br0-mal. Ezt a karbantartási ablak bezárása előtt tegye, nem utána, mert a Pi, amely elvesztette az alapértelmezett útvonalát, elérhetetlen arról a hálózatról, amelyet a javításához használna.