Warum ein gemeinsames TAP-VPN weiterhin HTTPS auf dem Portal braucht
Ein TAP-VPN authentifiziert den Peer, nicht den Dienst dahinter. Behalten Sie die Hostnamen-Validierung auf dem Portal und isolieren Sie Nachbarn, denen Sie nicht trauen.
Zwei Geräte besitzen gültige VPN-Zugangsdaten und teilen sich ein gebrücktes Ethernet-Segment. Nur eines von ihnen soll für das Büroportal antworten, und das andere kann die Portaladresse auf diesem Segment trotzdem beanspruchen. Der Tunnel hat seine Aufgabe erfüllt: Er hat beide Peers authentifiziert und jeden Pfad zum Server verschlüsselt. Was er nicht getan hat, ist zu bestätigen, welcher von ihnen einen Dienstnamen besitzt, und genau diese Lücke ist der Grund, warum das Portal weiterhin ein gültiges Zertifikat braucht.
Was das VPN tatsächlich authentifiziert
Ein VPN-Handshake beantwortet eine Frage: Welcher Peer hat diesen Tunnel mit welchem Schlüsselmaterial abgeschlossen. Diese Antwort gilt pro Peer und pro Verbindung und sagt nichts über die Dienste aus, die dieser Peer danach bereitstellt. In einem TAP-Segment ist der Peer nicht einmal eine einzelne Adresse, weil er jede MAC und jede IP präsentieren kann, die die Bridge zu lernen bereit ist. Die Authentifizierung endet am Tunnelendpunkt, nicht an der Anwendung.
Trennen Sie die drei Fragen, statt sie zu einer zu verschmelzen. Jede hat ihren eigenen Mechanismus und ihre eigene Fehlerart.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Ein Deployment kann einen perfekt authentifizierten Tunnel und einen völlig unauthentifizierten Dienst dahinter haben. Es kann auch ein validiertes Zertifikat auf einem Host haben, dessen Adresse der zweiten Schicht ein anderer Peer beansprucht, und deshalb gehören beide Kontrollen ins Design, statt dass eine die andere ersetzt. Die Tabelle ist das ganze Argument in drei Zeilen.
ARP in einem gemeinsam genutzten Segment ist kein Verzeichnis
ARP ordnet einer IPv4-Adresse eine MAC im lokalen Link zu und akzeptiert Antworten von jedem in diesem Link. In einem freizügigen gebrückten Segment kann ein Peer eine Adresse beanspruchen, die zu einem anderen Gerät gehört, und die Bridge leitet Frames an den weiter, der zuletzt geantwortet hat. Die Verschlüsselung jedes Client-Pfads zum Server ändert daran nichts, weil Frames entschlüsselt werden, bevor sie die Bridge erreichen. Die Vertrauensgrenze von ARP ist das Segment, nicht der Tunnel.
Sehen Sie nach, was der Host tatsächlich gelernt hat: ip neigh show listet aktuelle Zuordnungen und ihren Zustand, und ein Eintrag, der im Normalbetrieb zwischen zwei MAC-Adressen wechselt, ist ein Symptom, das untersucht werden sollte, statt es abzutun. In einem gesunden kleinen Segment bleiben solche Einträge lange stabil.
Peer-Isolation und Bridge-Policy gibt es genau für diesen Fall. Ein geroutetes Design ist meist die bessere Antwort, wenn der Dienst nur IP ist und die Geräte keinen Grund haben, die Frames des anderen überhaupt zu sehen.
Behalten Sie die Zertifikatsvalidierung dort, wo der Dienst ist
Das TLS der Anwendung beantwortet die Frage, die der Tunnel nicht kann: ist das der Dienst, den ich erreichen wollte. Der Browser prüft den Hostnamen gegen das Zertifikat, und diese Prüfung ist der einzige Teil der Kette, der das Portal statt den Peer benennt.
Prüfen Sie, was der Server präsentiert, bevor Sie die Warnung für kosmetisch halten. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal gibt die Kette und die alternativen Namen des Subjekts aus. Fehlt der eingegebene Name in dieser Liste, ist die Warnung korrekt und das Zertifikat muss repariert werden. Nutzer dazu anzuleiten, sie wegzuklicken, macht eine funktionierende Kontrolle zur Dekoration.
Der OpenVPN-Bridging-Leitfaden beschreibt das Ethernet-Modell und die Policy-Optionen darum herum und ist die richtige Referenz dafür, was das Segment erlauben soll. Lesen Sie ihn, bevor Sie eine Bridge-Regel lockern, denn das dort beschriebene Modell ist das, was jede Prüfung oben voraussetzt.
Entscheiden Sie, ob diese Peers überhaupt ein Segment teilen sollten
Die billigste Lösung ist meist, die zweite Schicht nicht mehr zu teilen, wenn nur IP-Erreichbarkeit gefordert ist. Ein geroutetes VPN gibt jedem Client seine eigene Adresse, entfernt die gemeinsame Broadcast-Domäne und macht Peer-to-Peer-Verkehr zu einer Policy-Entscheidung statt zu einem Standard. Das Portal hat dann eine Adresse zu schützen und keine Nachbarn, die sie beanspruchen können.
Wenn das Segment bleiben muss, prüfen Sie die serverseitige Einstellung, die Clients zueinander durchlässt: grep -n client-to-client /etc/openvpn/server.conf. Ist sie deaktiviert, läuft der Client-Verkehr über den Server und kann dort gefiltert werden. Ist sie aktiviert, tauschen Peers Frames direkt über die Bridge aus, und Ihre Filterpunkte sind die Bridge und die Host-Firewall.
Notieren Sie, auf welche Schutzmaßnahmen jeder Host tatsächlich angewiesen ist: Tunnel-Authentifizierung, Segment-Isolation oder Anwendungs-TLS. Ein Host, der auf alle drei setzt, ist in Ordnung. Ein Host, der auf die erste setzt und annimmt, die anderen beiden kämen mit ihr, ist derjenige, der am Ende den falschen Inhalt ausliefert.