Geroutetes oder gebrücktes VPN: Entscheiden Sie nach dem, was der Client erreichen muss

Am selben Tag kommen zwei Tickets: Ein Nutzer braucht eine interne Web-App, und ein Ingenieur braucht ein Laborgerät, das sich verhält, als stünde es im selben Ethernet-Segment. Beide werden mit setzen Sie sie auf das VPN beantwortet, und dort beginnt der Ärger. Ein gerouteter Tunnel und ein gebrückter Tunnel spannen unterschiedliche Beziehungen auf, und nur eine davon passt zu jeder Anfrage. Die Topologie zu wählen ist eine Zugangsentscheidung, keine Kryptografie-Einstellung.

Zwei Anfragen, die am Ticketschalter gleich aussehen

Die Anforderung des Mitarbeiters ist ein Dienst, über IP erreichbar, von einem Gerät, das Sie nicht kontrollieren. Die Anforderung des Ingenieurs ist auf Link-Ebene: das Gerät erwartet Ethernet-Frames und Broadcast-Erkennung zu sehen, und womöglich DHCP aus dem Segment, in dem es sich wähnt.

Das sind verschiedene Fragen, und beide mit einer Brücke zu beantworten erweitert den Zugang des Mitarbeiters ohne Grund auf das ganze Büro-LAN.

Schreiben Sie die Anforderung als Satz, bevor Sie wählen: welche Ziele, welche Protokolle und welche Gegenstellen lokal erscheinen müssen. Ist die Antwort ein Host und ein Port, deckt Routing das ab. Ist die Antwort eine Beziehung auf Frame-Ebene mit Geräten, die nur Broadcast sprechen, ist die Brücke vielleicht die einzige Option. Alles dazwischen verdient ein Testsegment statt des Produktions-LAN.

Eine Route ist schmaler als LAN-Mitgliedschaft

Ein gerouteter Client erhält eine Adresse in einem Tunnel-Subnetz und Routen für die Präfixe, die Sie wählen. Er erreicht den Anwendungsserver und sonst nichts, wenn die Richtlinie das sagt. Das Gateway wird zum Durchsetzungspunkt, sofern jeder relevante Pfad es kreuzt.

Verwechseln Sie eine Route nicht mit einer Berechtigung. Einem Client zu sagen, wie er ein Subnetz erreicht, hindert ihn nicht daran, ein anderes Ziel zu versuchen.

Setzen Sie Zugangskontrolle dort ein, wo sie den Fluss tatsächlich durchsetzen kann, und lassen Sie die eigenen Berechtigungen der Anwendung bestehen. Eine breite Weiterleitungsregel oder eine vergessene zweite Schnittstelle kann mehr gewähren, als das Diagramm nahelegt. Lesen Sie die wirksamen Regeln statt der beabsichtigten. Testen Sie dann ein Ziel, das scheitern müsste, denn eine Richtlinie, die niemand zu verletzen versucht hat, ist eine Hypothese.

Eine Brücke verändert die Zulassungsfrage

Bridging verbindet eine physische Schnittstelle und ein TAP-Gerät zu einem Software-Switch, sodass entfernte Geräte derselben Broadcast-Domäne beitreten. Das ist eine echte Fähigkeit und ein echtes Risiko: Das entfernte Gerät ist kein gerouteter Gast mehr, es ist Teilnehmer.

Entscheiden Sie, welche Geräte beitreten dürfen, welche Frame-Typen passieren müssen und wo unerwünschte Interaktion blockiert wird. Adressierung und DHCP-Autorität werden Teil des gemeinsamen Netzes, und zwei DHCP-Server in einem Segment erzeugen genau das Chaos, das Sie erwarten.

Für das Gerät passt ein eigenes Testsegment meist besser als das Büro-LAN. Halten Sie den Verwaltungszugang außerhalb des Experiments und legen Sie fest, wie der vorübergehende Teilnehmer nach Abschluss entfernt wird.

Filterung gibt es in beiden Topologien

Eine Brücke ist nicht von Natur aus unfilterbar, und eine Route ist nicht von Natur aus sicher. Linux-Bridge-Filterung hat eigene Hooks und eigene Regelsyntax, und eine Regel für geroutete IP-Weiterleitung gilt nicht automatisch für gebrückte Frames.

Prüfen Sie, was die Plattform tatsächlich unterstützt, bevor Sie eine Grenze versprechen:

bridge link show
nft list ruleset

TUN und TAP beschreiben den Verkehr der Schnittstelle, nicht die Chiffre. Der Wechsel der Schnittstellen behebt davon nichts: Peer-Authentifizierung, ein gestohlener Schlüssel und eine veraltete Kryptografie-Richtlinie überstehen die Änderung alle. Beide Enden brauchen weiterhin Einstellungen, die zusammenpassen und noch unterstützt werden.

Beweisen Sie die Grenze mit drei Versuchen

Abnahme sind drei Beobachtungen, keine Diagrammprüfung. Die geforderte Operation muss funktionieren, ein unabhängiges Ziel muss scheitern, und die Verwaltungsdienste des Gateways selbst müssen unerreichbar bleiben.

Führen Sie den erlaubten und den verweigerten Pfad vom selben Client aus und protokollieren Sie beide:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Für eine Brücke kommen die Link-Ebene-Prüfungen hinzu: ob der erlaubte Discovery-Verkehr passiert, ob die Adressierung von der vorgesehenen Autorität kommt und ob der vorübergehende Teilnehmer nach dem Entfernen verschwunden ist. Wenn schlichtes geroutetes IP die Anforderung bereits erfüllt, braucht der Beitritt zum Büro-Ethernet-Segment eine eigene Begründung, und sie sollte vor der Änderung niedergeschrieben werden.