Waarom een gedeelde TAP VPN nog steeds HTTPS op het portaal nodig heeft

Twee apparaten hebben geldige VPN-inloggegevens en delen één overbrugd Ethernet-segment. Slechts één ervan hoort namens het kantoorportaal te antwoorden, en de ander kan de portaaladressen op dat segment nog steeds claimen. De tunnel deed zijn werk: hij authenticeerde beide peers en versleutelde elk pad naar de server. Wat hij niet deed, is bevestigen wie van hen een dienstnaam bezit, en dat gat is de reden waarom het portaal nog steeds een geldig certificaat nodig heeft.

Wat de VPN werkelijk authenticeert

Een VPN-handshake beantwoordt één vraag: welke peer heeft deze tunnel voltooid, en met welk sleutelmateriaal. Dat antwoord geldt per peer en per verbinding, en het zegt niets over de diensten die die peer daarna aanbiedt. Op een TAP-segment is de peer niet eens één adres, omdat hij elk MAC en elk IP kan presenteren dat de bridge bereid is te leren. Authenticatie stopt bij het tunneleindpunt, niet bij de applicatie.

Scheid de drie vragen in plaats van ze tot één samen te voegen. Elk heeft zijn eigen mechanisme en zijn eigen faalwijze.

Een implementatie kan een perfect geauthenticeerde tunnel hebben en een volledig ongeauthenticeerde dienst erachter. Hij kan ook een gevalideerd certificaat hebben op een host waarvan het laag-twee-adres door een andere peer wordt geclaimd, en daarom horen beide controles in het ontwerp in plaats van dat de ene de andere vervangt. De tabel is het hele argument in drie rijen.

ARP op een gedeeld segment is geen adresboek

ARP koppelt een IPv4-adres aan een MAC op de lokale link en accepteert antwoorden van iedereen op die link. Op een toegeeflijk overbrugd segment kan een peer een adres claimen dat bij een ander apparaat hoort, en de bridge stuurt frames door naar degene die het laatst antwoordde. Versleuteling van elk klantpad naar de server verandert dat niet, omdat frames worden ontsleuteld voordat ze de bridge bereiken. De vertrouwensgrens van ARP is het segment, niet de tunnel.

Kijk wat de host werkelijk heeft geleerd: ip neigh show toont de huidige toewijzingen en hun status, en een vermelding die tijdens normaal bedrijf tussen twee MAC-adressen wisselt, is een symptoom dat onderzoek verdient in plaats van afwijzing. Op een gezond klein segment blijven zulke vermeldingen lang stabiel.

Peer-isolatie en bridgebeleid bestaan precies voor dit geval. Een gerouteerd ontwerp is meestal het betere antwoord wanneer de dienst alleen IP is en de apparaten geen enkele reden hebben om elkaars frames te zien.

Houd de certificaatvalidatie waar de dienst is

De TLS van de applicatie beantwoordt de vraag die de tunnel niet kan: is dit de dienst die ik wilde bereiken. De browser controleert de hostnaam tegen het certificaat, en die controle is het enige deel van de keten dat het portaal noemt in plaats van de peer.

Onderzoek wat de server presenteert voordat u besluit dat de waarschuwing cosmetisch is. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal drukt de keten en de alternatieve namen van het subject af. Als de naam die u hebt getypt niet in die lijst staat, is de waarschuwing correct en is het certificaat wat moet worden hersteld. Gebruikers leren erdoorheen te klikken maakt van een werkende controle decoratie.

De OpenVPN-bridgehandleiding beschrijft het Ethernet-model en de beleidsopties eromheen, en het is de juiste referentie voor wat het segment hoort toe te staan. Lees hem voordat u een bridgeregel versoepelt, want het model dat hij beschrijft is wat elke controle hierboven veronderstelt.

Beslis of die peers überhaupt een segment moeten delen

De goedkoopste oplossing is meestal stoppen met het delen van laag twee wanneer de eis alleen IP-bereikbaarheid is. Een gerouteerde VPN geeft elke klant zijn eigen adres, verwijdert het gedeelde broadcastdomein en maakt verkeer tussen peers een beleidsbeslissing in plaats van een standaard. Het portaal heeft dan één adres te beschermen en geen buren die het kunnen claimen.

Als het segment moet blijven, controleer dan de serverinstelling die clients elkaar laat bereiken: grep -n client-to-client /etc/openvpn/server.conf. Als die is uitgeschakeld, gaat klantverkeer via de server en kan daar worden gefilterd. Als die is ingeschakeld, wisselen peers frames rechtstreeks via de bridge uit, en uw filterpunten zijn de bridge en de firewall van de host.

Schrijf op op welke beschermingen elke host werkelijk vertrouwt: tunnelauthenticatie, segmentisolatie of applicatie-TLS. Een host die op alle drie vertrouwt, is in orde. Een host die op de eerste vertrouwt en aanneemt dat de andere twee daarmee meekwamen, is degene die uiteindelijk de verkeerde inhoud serveert.