Behandeln Sie ein VPN-bereit-Siegel als ein Merkmal eines Geräts, das auch routen, segmentieren und ausfallsicher umschalten muss, denn das Siegel sagt nichts darüber, wie viele getrennte Netze das Gerät aufnehmen kann. Beginnen Sie mit einem Fähigkeitsprotokoll für das genaue Modell und die Firmware und vergleichen Sie dieses Protokoll dann mit den Abläufen, die der Standort braucht. Marketingseiten listen Anschlüsse; sie listen selten VLAN-Zugehörigkeit, Failover-Richtlinie oder Tunnelumfang. Das Protokoll kostet etwa zwanzig Minuten und entscheidet die meisten Kaufdebatten, bevor die Hardware eintrifft.

Das genaue Gerät zuerst festnageln

Modellnamen wandern über Firmware-Generationen, und dasselbe Gehäuse kann je nach Release mit einem anderen Switch-Treiber ausgeliefert werden. Lesen Sie die Board-Identität vom Gerät selbst statt vom Karton, damit jede spätere Aussage an etwas gebunden ist, das Sie reproduzieren können. Ein Befehl deckt Modell, Boardname und Firmware-Release unter OpenWrt ab, und die entsprechenden Bildschirme gibt es in den meisten Business-Firmwares.

ssh [email protected] 'ubus call system board'
cat /etc/openwrt_release

Schreiben Sie diese Zeichenfolgen ungekürzt ins Protokoll. Trennen Sie dann die gewöhnliche Routing-Aufgabe von der Tunnel-Aufgabe. Ein Gerät, das Pakete gut weiterleitet, kann einen Tunnel trotzdem nicht terminieren, und ein Gerät, das einen Tunnel terminiert, hat vielleicht keine Möglichkeit, zwei lokale Netze auseinanderzuhalten. Werden beide als eine Anforderung behandelt, bleibt die Diskrepanz verborgen, bis das Gerät bereits im Rack sitzt, konfiguriert und halb vertraut ist.

Die LAN-Struktur erfassen, nicht die Portzahl

Vier Buchsen bedeuten meist einen Switch, und ein Switch bedeutet eine Broadcast-Domäne, sofern keine VLANs konfiguriert sind. Das ist für ein flaches Heimnetz in Ordnung und falsch für einen Standort, der ein Gästesegment, ein Managementsegment und ein isoliertes Kamerasegment auf demselben Gerät will. Halten Sie fest, welche Ports zu welchem VLAN gehören, welche VLANs die CPU erreichen und welche Schnittstellen Adressen tragen.

Wo die Firmware VLANs anbietet, entscheidet die Schnittstellenliste, wie viele verschiedene Richtlinien Sie schreiben können. Ein VLAN, das am Switch definiert, aber nie als Schnittstelle zugewiesen wurde, hat keine Adresse und keine Firewall-Zone und kann daher allein nichts durchsetzen.

Field to recordExample entryReview stops if
Ports and VLAN membershipports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20the datasheet offers only a socket count
Routed interfacesbr-lan 192.168.88.1/24, vlan20 192.168.99.1/24two subnets cannot hold separate policies
WAN method and failoverDHCP on wan, PPPoE on wan2, policy route to wan2 on lossonly one uplink is configurable
Tunnel role and scopeWireGuard peer on the router, only 192.168.88.0/24 routed insidethe router can only pass another tunnel through

Lesen Sie den Switch-Zustand, statt dem Menü zu vertrauen. Bei älteren OpenWrt-Zielen gibt das Switch-Werkzeug die konfigurierten Geräte aus, bei DSA-Zielen melden die Bridge-Werkzeuge dieselben Fakten pro Port, weshalb das Firmware-Release ins Protokoll gehört.

WAN- und Failover-Verhalten festhalten

Zugangsmethode, Adressinhaberschaft und Failover-Reihenfolge gehören in eine Zeile pro Uplink, weil ein Tunnel, der einen WAN-Wechsel übersteht, von allen drei abhängt. Eine PPPoE-Sitzung verbindet sich mit einer neuen Adresse neu und verliert dabei den Tunnel, während ein DHCP-Uplink, der seine Lease behält, das vielleicht nicht tut.

Failover braucht auch eine Richtlinienentscheidung. Allen Verkehr auf die Backup-Leitung zu schicken ist einfach; den Tunnel auf der primären zu halten, während gewöhnlicher Webverkehr die Backup-Leitung nutzt, erfordert Policy-Routing, und nicht jede Firmware bietet es. Notieren Sie, ob der Tunnel an einen Uplink gebunden ist und was das Gerät mit bestehenden Sitzungen macht, wenn dieser Uplink verschwindet. Halten Sie die Routing-Tabelle als Beleg fest, nicht das Failover-Kästchen.

Einen erlaubten und einen verbotenen Fluss testen

Das Protokoll lohnt sich nur, wenn das Gerät dagegen abgenommen werden kann. Wählen Sie einen Fluss, der funktionieren muss, einen, der nicht darf, und führen Sie beide von einem Client im betreffenden Segment aus. Ein Tunnel, der jedes Subnetz trägt, ist ein Fehlschlag, wenn die Anforderung ein Subnetz war.

Bestätigen Sie dann die Sperre, denn eine permissive Voreinstellung ist die übliche Überraschung. Das Gästesegment darf die Managementadresse nicht erreichen, und die Prüfung sollte eine Zeitüberschreitung oder Ablehnung zeigen, nicht eine Anmeldeseite.

curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1

Wenn der erlaubte Fluss funktioniert und der verbotene ebenfalls, fehlt die Segmentierung, auch wenn die Menüs anderes nahelegten. Wenn beide scheitern, sind Tunnelumfang oder Rückweg falsch, und das WAN-Protokoll erklärt meist, was davon. Bewahren Sie die beiden Ergebnisse beim Fähigkeitsprotokoll auf, damit der nächste Prüfer sieht, was abgenommen wurde, auf welcher Firmware und an welchem Datum.

Ähnliche Artikel