Warum Ihr VPN-Sensor das VLAN-Tag der Filiale nie sieht

Ein Sensor auf der VPN-Seite sieht zwei Filial-VLANs als gewöhnlichen IP-Verkehr, und das Tag, das jede Filiale auf ihrer eigenen Leitung kennzeichnete, ist verschwunden. Genau das leistet ein gerouteter Tunnel: Er stellt Pakete wieder her, nicht die Ethernet-Frames, die sie zugestellt haben. Ob das fehlende Tag eine Rolle spielt, hängt ganz von der Frage ab, die Sie dem Sensor stellen. Arbeiten Sie die vier Prüfungen unten der Reihe nach ab, und Sie wissen, welcher Beobachtungspunkt sie beantworten kann.

Erstens: Stellen Sie fest, was Ihr Tunnel wiederherstellt

Eine TUN-Schnittstelle überträgt IP-Pakete, also endet der VLAN-Header des Filial-Frames am Router, der den Verkehr in den Tunnel geschoben hat. Eine TAP-Schnittstelle überträgt Ethernet-Frames, was bedeutet, dass Tags überleben können, wenn die Bridge und die VLAN-Zulassungsregeln sie durchlassen. Lesen Sie den Schnittstellentyp, bevor Sie überlegen, was ein Mitschnitt enthalten sollte.

Keine der beiden Wahlmöglichkeiten ist ein Defekt. Die beiden Entwürfe beantworten unterschiedliche Fragen und lassen das Tag an unterschiedlichen Stellen.

Bestätigen Sie die Schnittstelle selbst, statt sie aus dem Produktnamen abzuleiten. Die Verbindungsdetails nennen die Geräteart und zeigen die geltenden Flags, und ein Mitschnitt auf einem TUN-Gerät bekommt keinen Ethernet-Header, nur weil Sie danach gefragt haben. Wenn auf einem TUN-Mitschnitt doch Tags auftauchen, lesen Sie fast sicher eine andere Schnittstelle oder einen Tunnel, der Frames in seiner Nutzlast trägt. Notieren Sie, welcher Fall vorliegt, bevor Sie fortfahren.

Zweitens: Platzieren Sie den Sensor dort, wo das Objekt noch existiert

Drei Positionen decken die meisten gerouteten Entwürfe ab: das Ethernet-Segment der Filiale, das äußere Netz zwischen den Tunnelendpunkten und den Pfad nach der Tunnelverarbeitung. Jede sieht ein anderes Objekt, und das Tag existiert nur an der ersten. Eine Sensorposition zu wählen ist eine Entscheidung darüber, welches Objekt die Richtlinie braucht, keine Frage der Bequemlichkeit.

Formulieren Sie die Richtlinienfrage so, dass die Tabelle sie beantworten kann, und sie löst sich meist von selbst. Muss die Regel wissen, von welcher Filiale ein Paket kam, kann die Präfixzuordnung weiter hinten genügen, aber nur solange diese Zuordnung genau und eindeutig ist. Muss die Regel wissen, an welchem Port der Frame ankam, brauchen Sie die erste Position, denn nichts weiter hinten kann das rekonstruieren. Sensoren, die aus Gewohnheit statt aus einer Frage platziert werden, sind der Grund, warum Teams am Ende ein Feld verlangen, das der Entwurf nie trug.

Ein Tunnel, der Ethernet trägt, ist ein anderer Entwurf und braucht eine eigene Prüfung dessen, was die Endpunkte bewahren oder umschreiben. Die bloße Wahl von TAP definiert noch immer nicht die Bridge, die VLAN-Zulassungsregeln oder die Inspektionsrichtlinie.

Drittens: Verdienen Sie sich den Quellkontext, statt ihm zu vertrauen

Ein Adressbereich pro Filiale ist der übliche Ersatz für VLAN-Identität, und er hält nur, solange die Zuordnung eins zu eins bleibt. Überlappende Präfixe, Übersetzung und ein gemeinsames Gateway durchbrechen diese Annahme jeweils auf eine Weise, die wie ein Datenqualitätsproblem aussieht und nicht wie ein Entwurfsproblem. Schreiben Sie die Zuordnung mit ihren Grenzen auf und sagen Sie, was mit einem Paket geschieht, das auf zwei Zeilen passt. Ein Präfix, das in zwei Filialen auftaucht, sollte ein Fehler sein, den Sie erkennen, kein Münzwurf, den Sie akzeptieren.

Vom Client gelieferter Kontext ist kein Nachweis der Zugehörigkeit. Er ist eine Behauptung und gehört in eine andere Spalte.

Wo der Unterschied zählt, nutzen Sie Zuordnungsdaten, die Sie kontrollieren: welche Tunnelinstanz die Verbindung angenommen hat, auf welcher Schnittstelle die Pakete ankamen, was die lokale Routentabelle über diesen Peer sagt. Ein vom Client geliefertes Label ist ein nützlicher Hinweis und eine nutzlose Autorisierungseingabe. Kann der Sensor die Zuordnung nicht aus seiner eigenen Sicht herstellen, braucht die Richtlinie eine breitere Regel statt einer selbstsicheren Vermutung.

Viertens: Bestätigen Sie den Antwortpfad und was die Entschlüsselung übersieht

Ein Sensor, der nur eine Richtung sieht, kann weiterhin gesund aussehen, weil Anfragen planmäßig eintreffen. Prüfen Sie den Antwortpfad ausdrücklich, und prüfen Sie ihn für denselben Fluss statt für allgemeine Erreichbarkeit. Halbduplex-Sichtbarkeit wird zu einer stillen Lücke in jeder zustandsbehafteten Schlussfolgerung, die Sie daraus ziehen.

Inneren IP-Verkehr wiederherzustellen ist ebenso wenig dasselbe wie die Anwendung darin zu sehen, denn TLS, das über den Tunnel getragen wird, bleibt TLS.

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

Diese beiden Befehle beantworten die Schnittstellenfrage und zeigen, was der Mitschnitt wirklich enthält, was schneller ist, als über die Architektur zu streiten. Ersetzen Sie den Schnittstellennamen, den Ihr Entwurf verwendet, und führen Sie den Mitschnitt aus, während der Fluss, der Sie interessiert, aktiv ist. Wenn auf einem TUN-Gerät kein Tag erscheint, lautet der Befund, dass der Entwurf geroutet statt gebrückt hat, nicht, dass der Sensor Daten verworfen hat. Bewegen Sie dann entweder den Sensor an eine Position, die das Tag sehen kann, oder schreiben Sie die Regel in Begriffen um, die die aktuelle Position tragen kann.