A WireGuard kézfogás működik, de az irodai alhálózat nem válaszol

A kézfogás befejeződik, wg show nemrég történt átvitelről számol be, és a szerver alagútcíme válaszol a pingre. A szerver LAN-ján lévő gazdagép viszont nem. Három feltételnek kell egyszerre teljesülnie: az ügyfélnek a LAN előtagját az alagútba kell irányítania, a szervernek továbbítania kell a csomagokat, és a válasznak visszaútra van szüksége. Ha a három közül egy hiányzik, a tünet ugyanaz.

Az AllowedIPs egyszerre hozzáférési lista és útválasztási tábla

Az ügyfélen a lista AllowedIPs dönti el, hogy mit lehet az adott partnernek küldeni, és azt is, hogy a WireGuard mely útvonalakat telepíti. Az a partnerbejegyzés, amely csak a szerver alagútcímét sorolja fel, egyetlen gazdagép-útvonalat telepít, így a LAN célpontjai soha nem kerülnek az alagútba. A LAN előtagjának hozzáadása az első ellenőrizendő dolog, és egyben az a változtatás, amely a legtöbbször hiányzik egy másolt konfiguráció után. Az alapértelmezett útvonalra szélesített partner másik kialakítás, és az ügyfél internetforgalmát is átmozgatja.

Tartsa külön bejegyzésként a gazdagép-útvonalat és a LAN előtagját. Ha az irodának két alhálózata van, mindkettő a listára tartozik, és a hiányzó második előtag olyan hibát okoz, amely szelektívnek, nem pedig teljesnek látszik.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

A továbbítás és a fordítás a szerverre tartozik

A szervernek engedélyezett IP-továbbításra, az alagútból érkező forgalmat elfogadó továbbítási szabályra és a LAN-interfésze felé mutató fordítási szabályra van szüksége. A fordítás az, ami az irodai hálózat minden gazdagépének érintése nélkül működőképessé teszi a kialakítást. A válaszok ezután a szerverhez térnek vissza, nem pedig egy olyan címre, amelyről a LAN soha nem hallott. Enélkül minden gazdagépnek útvonalra van szüksége az alagút alhálózatához és egy azt engedélyező tűzfalszabályra, ami ritkán elfogadható egy másvalaki által kezelt hálózaton.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

A kézzel hozzáadott szabályok újraindításkor eltűnnek, ezért a szerverkonfiguráció hook-parancsaival kösse őket az interfészhez. Az a szabálykészlet, amely túléli az interfészét, az az út, ahogyan egy gép végül olyan alagút forgalmát fordítja, amely már nem létezik.

Amikor a LAN elköltözött, a szabály pedig nem

Az irodai alhálózatot újraszámozó routercsera ennek a hibának a klasszikus változata. Az alagút fent marad, a kézfogás friss marad, és a szerver mögött semmi nem válaszol, mert a fordítási szabály még mindig a régi címet nevezi meg. A telepítőszkriptek gyakran beleégetik a szerver LAN-címét egy POSTROUTING-szabályba, és az újraszámozás után ez a cím egyetlen interfészen sem létezik. A csomagok ezután olyan célpontra íródnak át, amely nem tud válaszolni.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Hasonlítsa össze a két kimenetet. Az az átfordítási cél, amely nem jelenik meg az interfészek listáján, maga a hiba, és javítása egyetlen sor módosítása, ha egyszer meglátta. A szabály egy generált unitban is lakhat, nem a WireGuard-konfigurációban, ezért szerkesztés után töltse újra azt a unitot, és ellenőrizze, hogy a következő indítás nem írja felül a módosítását.

Két NAT mögötti telephelynek találkozóhely kell

Amikor egyik oldal sem fogad bejövő kapcsolatokat, a gyakorlati válasz egy kis gazdagép nyilvános címmel és két WireGuard-interfésszel. Minden telephely kifelé kapcsolódik, a középső gazdagép az egyes partnerek LAN-ját a saját AllowedIPs-listájában sorolja fel, a továbbítás pedig csomagokat visz a két alagút között. Egyik telephely tűzfalán sem kell semmit megváltoztatni, ezért ez a kialakítás könnyen terjed.

A telephelyek közötti útválasztás megőrzi az eredeti forráscímeket, és ezáltal értelmessé teszi a gazdagépenkénti naplózást. A középső gazdagépen a fordítás egyszerűbb, ha a két LAN átfed, de a forrásazonosság naplókban való elvesztésének árán. Döntse el, melyik tulajdonság számít, mielőtt választ.

Válassza külön a rétegeket négy ellenőrzéssel

Rétegenként végezzen egy ellenőrzést, ahelyett hogy három dolgot változtatna meg és reménykedne. Az első a kézfogás korát és az egyes partnerek számlálóit mutatja. A második azt mutatja, hogy az ügyfél valóban az alagútba irányítja-e azt a célpontot. A harmadik és a negyedik azt mondja meg, hogy a kérés megérkezett-e, és hogy egy szabályzat eldobta-e érkezés után.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Az a kérés, amely megérkezik és nem vált ki választ, a válasz útvonalára vagy a LAN gazdagépére mutat. Az a kérés, amely soha nem érkezik meg, a AllowedIPs vagy az ügyfél útvonalára mutat. Ez a két kimenet különböző javításokat igényel, és a rögzítés az, ami megkülönbözteti őket.