Wat een bedrijfsfirewall wel en niet kan zien binnen een VPN

Dezelfde laptop bereikt de VPN vanaf thuis en kan vanaf kantoor geen verbinding maken, dus iemand moet het verkeer lezen. Blokkeren en lezen zijn gescheiden bevoegdheden, en alleen de tweede heeft een plek op het pad nodig plus een certificaat dat de client vertrouwt. Een tussenbox die je handshake weggooit, heeft niets geleerd over wat je zou hebben verstuurd. Bepalen met welke van de twee je te maken hebt, is het hele werk.

Blokkeren en lezen zijn verschillende bevoegdheden

Een weigering is goedkoop en luidruchtig: de socket gaat open en niets antwoordt, of er komt meteen een reset. Niets daarvan betekent inspectie, want er is geen payload over de lijn gegaan.

Lezen vereist een eindpunt dat de bescherming beëindigt, zich met een certificaat bewijst en een nieuwe verbinding verder opzet. Dat eindpunt moet op het pad liggen en door de client worden vertrouwd. Een firewall die alleen pakketten doorstuurt, heeft noch positie noch bevoegdheid.

Wat de wikkel gratis weggeeft

Elk tunnelpakket heeft een buitenkant, en de buitenkant moet routeerbaar zijn. Dat betekent twee adressen, een protocol, een poort en een lengte, plus timing en volume. Elke router verwerkt die velden al, en een NAT herschrijft het adres en de poort om zijn mappingtabel consistent te houden. De payload blijft verzegeld, dus de waarneming stopt bij het feit dat er een tunnel tussen twee hosts bestaat.

Een hostnaam zit daar niet bij. Sites lekken via andere deuren, en de breedste is DNS: als de laptop nog de lokale resolver vraagt, verschijnen de namen in het helder.

Timing en volume verdienen respect zonder overdreven te worden. Bytes per minuut kunnen laten zien dat een grote overdracht om 14:20 begint; ze kunnen niet laten zien welk bestand bewoog. Dat is een echte onthulling over gedrag, en een andere categorie dan inhoud lezen.

TLS-onderschepping vereist een root die je al vertrouwt

Een inspectieapparaat breekt TLS niet; het beëindigt het. De client krijgt antwoord met een certificaat van een root die de organisatie bezit, en een tweede verbinding gaat naar de echte bestemming. De client accepteert dit omdat die root in zijn truststore staat, en daarom toont een beheerde laptop geen waarschuwing. Cryptografie werd nooit verslagen; het eindpunt werd verplaatst.

Daarom laat de opzet ook sporen na. De uitgever op de getoonde keten hoort bij de organisatie en niet bij een publieke CA, en een client kan dat zonder speciaal gereedschap zien. Een keten die eindigt bij een interne root is de handtekening van onderschepping, geen storing.

Waarom een VPN-kanaal geen HTTPS-sessie is

Een VPN-datakanaal geeft een inspecteur geen dergelijk houvast. IKEv2 en WireGuard draaien hun eigen handshakes en sleutelschema’s, zonder TLS om te beëindigen, terwijl OpenVPN TLS leent voor zijn controlekanaal in een gewijzigde vorm voordat het data op zijn eigen manier beschermt. Een proxy gebouwd voor HTTPS herkent die sessie niet als iets wat hij kan parsen.

Een apparaat dat een sessie niet kan parsen, kan hem nog steeds weggooien. Daarom lijkt VPN-blokkade meestal op een time-out en niet op een certificaatwaarschuwing, en daarom verandert een uitzondering niets.

Controleer het vanaf je eigen machine

Begin met de keten die de site toont. De sitegegevens in de browser tonen de uitgever, en de opdrachtregel meldt hetzelfde zonder de samenvatting:

openssl s_client -connect example.com:443 -servername example.com

Scheid daarna een geweigerde handshake met tellers van gefilterd binnenverkeer. Log de transportpoort vóór elke drop-regel en lees ze na de poging:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

Geen logregel op de buitenste socket betekent dat de handshake nooit is vertrokken, dus het pad weigert de tunnel. Een voltooide handshake waarbij alleen sommige bestemmingen falen, betekent dat de tunnel werkt en het beleid erbinnen niet. Geen van beide resultaten vereiste het lezen van een byte payload.

Het lezen dat echt gebeurt, zit aan de randen: een gesplitste tunnel geeft interne HTTPS aan een bedrijfsproxy, en een concentrator in eigendom van de werkgever legt bij de uitgang alles bloot. Wat je ook vindt, schakel certificaatverificatie niet uit om een verbinding te forceren, want die controle is het enige dat inspectie van een aanvaller scheidt.