Ein breiter IPsec-Selektor ist keine Berechtigung für jeden Dienst

Zwei Gegenstellen vereinbaren, ein ganzes Subnetz zu schützen, und jemand liest diese Vereinbarung als Erlaubnis, jeden Dienst darin zu erreichen. Das ist der Mythos: Der Selektor sagt, welchen Verkehr der Tunnel zu tragen bereit ist, und er sagt nichts darüber, welche Dienste die Organisation erlaubt. Ein Gerätepaar kann legitim einen breiten Adressbereich aushandeln, während die Zugriffsrichtlinie darin zwei Ports erlaubt, und beide Aussagen bleiben gleichzeitig wahr.

Geschützte Abdeckung ist keine Autorisierung

Ein Verkehrsselektor ist Teil der Tunnelvereinbarung. Er engt ein oder bestätigt, was die Gegenstellen untereinander verschlüsseln, und ein breiter Selektor ist oft das Einfachste im Betrieb, wenn beide Seiten viele Flüsse zu tragen haben. Der Dienstfilter ist eine andere Kontrolle an einer anderen Stelle des Pfades und entscheidet, was tatsächlich genutzt werden darf, nachdem das Paket entschlüsselt wurde. Den Filter zu entfernen, damit ein Test durchgeht, macht aus einer Richtlinienentscheidung einen Unfall.

Halten Sie die beiden Aufzeichnungen im Entwurfsdokument getrennt, denn wer nur den Selektor sieht, wird eine Autorisierung ableiten, die nie erteilt wurde. Zwei Zeilen in einem Änderungsdatensatz verhindern das, und sie kosten weniger Zeit als die Debatte, die folgt.

Beschreiben Sie einen Fluss von beiden Enden

Notieren Sie den Initiator, den Responder, Quelle und Ziel in der dargestellten Form, das Protokoll und beide Ports. Drehen Sie dann jede dieser Bezeichnungen für den anderen Endpunkt um, denn der kurzlebige Quellport eines Clients wird zum Zielport einer Antwort, und das entfernte Netz wird zum lokalen. Eine Konfiguration, die ohne diese Umkehrung von einer Seite auf die andere kopiert wird, ist der Grund, warum Filter am Ende genau die falsche Richtung erlauben. Schreiben Sie die Tabelle einmal und bauen Sie beide Filter daraus.

Einigen Sie sich auf das Auswahlmodell, bevor Sie etwas kopieren, denn ein richtlinienbasiertes Design und ein routenbasiertes Design drücken dieselbe Absicht durch verschiedene Objekte aus. Schreiben Sie den Modellnamen neben den Fluss, sonst verbringt der nächste Ingenieur einen Nachmittag damit, Objekte abzugleichen, die nie vergleichbar waren.

Finden Sie den Filter, der tatsächlich gilt

Auf einer ASA ist der VPN-Filter eine ACL, die an eine Gruppenrichtlinie gebunden und auf Verkehr nach der Entschlüsselung und vor der Verschlüsselung angewendet wird. Ciscos Dokumentation zu Gruppenrichtlinien beschreibt auch Vererbung, einschließlich eines Werts auf Benutzerebene, der den Wert der Gruppenrichtlinie ersetzt. Die ACL, die Sie bearbeitet haben, muss also nicht die ACL sein, die die Sitzung vor Ihnen steuert. Dasselbe gilt für das Benutzerobjekt, das die Gruppe überschreiben kann, ohne viel sichtbare Spur zu hinterlassen.

Prüfen Sie die wirksame Sitzung statt des Objekts, von dem Sie glauben, es geändert zu haben, und notieren Sie, welches Richtlinienobjekt sie liefert. Dieser eine Schritt löst erstaunlich viele Meldungen der Art der Filter ist richtig, aber er funktioniert nicht.

Richtung, Ports und der umgekehrte Fall

Die dokumentierte Konvention setzt das entfernte Netz oder die zugewiesenen Adressen entfernter Clients in die Quellposition und das lokale Netz in die Zielposition, wobei Antworten durch Tauschen der Adresspositionen ausgedrückt werden. Portregeln stehen über dieser Konvention und verdienen mehr Sorgfalt als die Adressen.

Das dokumentierte Modell kann zulassen, dass eine Zielportregel eine umgekehrte Initiierung beeinflusst, die denselben Quellport verwendet, was bedeutet, dass der Filter nicht einfach eine einseitige Anforderungsregel mit harmlosen Antworten ist. Denken Sie beide Initiierungsrichtungen ausdrücklich durch und schließen Sie den Fall ein, den Sie ablehnen wollen.

Dieselbe Dokumentation beschränkt den Filter auf anfängliche Verbindungen, er ist also keine universelle Durchsetzung jedes sekundären Kanals, den eine inspizierte Anwendung öffnet. Wo die vollständige Richtlinie diese Abdeckung braucht, gehört sie an eine separate Grenze statt in eine ACL, die über ihren Zweck hinaus gedehnt wird.

Testen Sie drei Fälle, bevor Sie es fertig nennen

Akzeptieren Sie den beabsichtigten Fluss, lehnen Sie einen Dienst ab, den die Richtlinie verbietet, und üben Sie den umgekehrten Fall, den Sie durchdacht haben. Führen Sie sie unter einem genehmigten Plan mit denselben Identitäten und Selektoren aus, die Sie einführen werden. Ein Test, der nur zeigt, dass der erlaubte Dienst funktioniert, demonstriert den Tunnel, nicht die Richtlinie.

Halten Sie die ausgehandelte Abdeckung und die Zugriffsentscheidung als zwei Aufzeichnungen, denn zu erklären, was eine VPN erlaubt, erfordert beide.