Ein Filial-Subnetz über den SonicWall-Internetausgang der Zentrale routen

Filialtelefone sollten über die Zentrale hinausgehen, während Filial-Laptops weiterhin das lokale WAN nutzen, und die Routingrichtlinie allein leistet das nicht. Eine Filialroute kann den Tunnel auswählen, aber die Tunnelrichtlinie muss den Datenverkehr annehmen, die Zentrale muss ihn weiterleiten und übersetzen, und die Antwort muss denselben Weg zurückkommen. Fehlt nur eines dieser drei, zeigt sich das Symptom bei einer Teilmenge von Clients, die genau dann das Internet verlieren, wenn der Tunnel steht.

Beginnen Sie mit dem Selektor, nicht mit der Route

Die Routingrichtlinie gleicht anhand einer Quelle ab, also muss die Quelle zuerst stabil sein. Legen Sie die ausgewählten Geräte in eine Adressgruppe, die ein Administrator pflegt, oder besser in ein eigenes Segment, dessen Mitgliedschaft der Geräterolle folgt. Wenn gewöhnlicher DHCP-Wechsel eine passende Adresse auf einen anderen Rechner verschieben kann, wählt die Richtlinie still den falschen Client, und der erste Bericht handelt meist von langsamem Surfen, das in Wahrheit ein Umweg ist.

Benennen Sie die Gruppe nach der Richtlinie, der sie dient, nicht nach einer Etage oder Abteilung, denn die Routingregel überlebt beides. Halten Sie fest, welche Geräte darin sind und wer eines hinzufügen darf.

Fügen Sie die Filialrichtlinie hinzu und verteidigen Sie dann ihre Reihenfolge

Auf dem SonicWall der Filiale wählt eine Routenrichtlinie die Quellgruppe aus, benennt die beabsichtigten Ziele und setzt die Tunnelschnittstelle als Gateway, wofür das unterstützte Tunnelschnittstellen-Design genau gedacht ist. Halten Sie Regeln für lokale und private Ziele über der breiten Internetregel, denn der erste Treffer gewinnt, und ein privates Präfix, das in den Tunnel geschoben wird, erreicht die Zentrale nur, um verworfen zu werden. Bewahren Sie auch die eigene Route der Firewall zu ihrem VPN-Peer, sonst folgt der Tunneltransport der Richtlinie, von der er abhängt. Nichts davon zwingt Sie, jeden bestehenden richtlinienbasierten Tunnel umzustellen; eine Tunnelschnittstelle ist eine unterstützte Wahl unter mehreren.

Die Reihenfolge ist der Teil, der sich versehentlich ändert. Wer eine Ausnahme hinzufügt, muss sie über der breiten Regel einfügen, und wer die breite Regel bearbeitet, kann das ganze Design mit einem einzigen Speichern umkehren. Schreiben Sie die beabsichtigte Reihenfolge neben die Richtlinie und prüfen Sie sie nach Firmware-Updates erneut, denn Schnittstellenbenennung und Richtliniendarstellung verschieben sich zwischen Versionen.

Vervollständigen Sie den Pfad in der Zentrale

Die Tunnelrichtlinie in der Zentrale muss den Verkehr annehmen, den die Filialroute nun auswählt. Ein standortübergreifender Selektor, der auf das private LAN der Zentrale begrenzt ist, ist keine Erlaubnis, beliebige öffentliche Ziele zu führen, daher braucht die Richtlinie die Filialquelle und den Zielbereich, den Sie tatsächlich beabsichtigen. Die Zentrale leitet diesen ankommenden Verkehr dann nach ihren eigenen Zugriffsregeln an ihren Internet-Uplink weiter, und SonicWalls Beispiel für den zentralen Ausgang enthält eine Quellübersetzung für das entfernte Netz am zentralen WAN. Ohne diese Übersetzung sieht die Gegenseite eine private Filialadresse und hat keinen Rückweg dorthin.

Antworten sind die andere Hälfte des Vertrags. Sie müssen durch den Tunnel oder durch die dafür erstellte zustandsbehaftete Übersetzung zurückkehren, und Verkehr zu privaten Standorten kann eine andere NAT-Behandlung benötigen als öffentlicher Ausgang. Halten Sie diese Regeln unterscheidbar, denn eine breite Übersetzungsregel, die jede interne Quelle verbirgt, macht spätere Protokollierung und Fehlersuche viel schwerer lesbar.

Entscheiden Sie, was die Gruppe tut, wenn der Tunnel ausfällt

Wenn der zentrale Ausgang eine Anforderung und keine Vorliebe ist, ist ein Rückfall auf das lokale WAN ein Compliance-Verstoß, selbst wenn Benutzer online bleiben. SonicOS dokumentiert eine Route mit verworfenem Tunnelinterface als den unterstützten Weg, ausgewählten Verkehr davon abzuhalten, einen unbeabsichtigten alternativen Pfad zu nehmen.

Gleichen Sie Umfang und Priorität dieser Route mit der installierten Version ab, und testen Sie sie, indem Sie den Tunnel herunterfahren, statt dem Etikett zu vertrauen. Eine Gruppe, die niemals lokal hinausgehen darf, sollte geschlossen scheitern, während eine Gruppe, in der Verfügbarkeit wichtiger ist, legitim zurückfallen darf; beides sind Entscheidungen, und keine sollte standardmäßig geschehen.

Prüfen Sie von drei Clients aus und rollen Sie dann sauber zurück

Ein Ping zum zentralen Gateway prüft das Falsche, weil er von der Firewall und nicht von einem ausgewählten Client ausgeht. Testen Sie stattdessen von Geräten aus, und testen Sie drei davon: ein ausgewähltes Gerät, ein gewöhnliches Gerät, das lokal bleiben soll, und eines, das von lokalen Diensten abhängt.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Vergleichen Sie, wo die öffentliche Anfrage tatsächlich aufgetaucht ist. Ein ausgewählter Client sollte das Internet über den Ausgang der Zentrale erreichen, und ein gewöhnlicher Client sollte auf der Gegenseite weiterhin die eigene Adresse der Filiale zeigen; 203.0.113.10 ist eine Dokumentationsadresse, die als Platzhalter für das Ziel dient, das Ihnen wichtig ist. Beziehen Sie DNS im selben Durchgang ein, denn ein Client, der den Resolver der Filiale fragt, kann eine vom Router ausgehende Abfrage mit anderer Quelle und damit anderer Route erzeugen.

Das Zurückrollen ist die gespeicherte Richtlinienreihenfolge plus die Adressgruppe. Stellen Sie die vorherige Reihenfolge wieder her, entfernen Sie die Gruppe aus der Richtlinie, und testen Sie beide Geräteklassen erneut. Bewahren Sie die exportierte Konfiguration mit dem Änderungsdatensatz auf, denn der nächste Ingenieur muss wissen, welche Regel die breite war, bevor jemand sie bearbeitet hat.