Twee VPN-hops achter elkaar: wie ziet uw verkeer echt?

Elk cliëntprofiel noemt één server, dus vanuit de gebruiker is er één tunnel en één plek waar de bescherming eindigt. Wat er na die eerste gateway gebeurt, is een ontwerpbeslissing die de cliënt nooit ziet, en de twee gangbare ontwerpen gedragen zich onder inspectie heel anders. In een seriële keten ontsleutelt de eerste gateway en versleutelt opnieuw. In een geneste keten verwijdert hij een buitenste laag en stuurt een binnenste tunnel door die hij niet kan openen. Het aantal hops is in beide identiek, daarom moet het verschil getekend worden en niet geteld.

Begin bij de cliënt en benoem beide uiteinden

Begin waar de gebruiker begint, in het verbindingsprofiel. Het bevat één extern adres, één authenticatiemethode en, wanneer het ontwerp dat ondersteunt, een routelijst. Label die buitenste tunnel van de cliënt naar gateway A en geef hem voorbeeldadressen: het tunneladres van de cliënt 10.77.0.2, dat van A 10.77.0.1 en het openbare eindpunt van A 198.51.100.10, uit het TEST-NET-2-documentatiebereik, zodat niets in het voorbeeld met een echte host kan botsen.

Niets in dat profiel noemt gateway B, en dat is geen defect. De tweede hop hoort bij A, en de enige verplichting van de cliënt is verkeer naar A brengen en aannemen wat terugkomt. Of A de tunnel beëindigt, doorstuurt of een nieuwe opent, is de vraag die de rest van deze wandeling beantwoordt, en die bepaalt wat A kan lezen.

Serieel: A ontsleutelt en versleutelt daarna opnieuw

In het seriële ontwerp beëindigt A het verkeer twee keer. Het verwijdert de bescherming van de cliënt, verkrijgt het IP-pakket van de toepassing en stuurt dat pakket dan door een tweede tunnel die A richting B opzet. Tussen die twee bewerkingen ligt het pakket in het doorstuurpad van A als een gewoon IP-pakket dat aan een privébestemming is geadresseerd.

Dat levert twee gevolgen op die je ronduit moet zeggen. A kan beleid op het binnenste pakket toepassen, in de vorm van routes, filterregels en loggen van bron en bestemming, en A moet twee sets inloggegevens aanhouden: één als server voor de cliënt en één als cliënt van B. Bescherming bestaat op elk moment, maar het beschermde object wisselt bij A van identiteit.

Daaruit volgt niet dat A de platte tekst van de toepassing leest. Wanneer de cliënt en de dienst TLS draaien en elkaars certificaten verifiëren, ziet A een stroom TLS-records in plaats van een leesbaar verzoek. Vaststellen waar die bescherming eindigt vereist een blik op de certificaatketen van de dienst, niet op het tunneldiagram.

Genest: A verwijdert alleen de buitenste laag

In het geneste ontwerp bouwt de cliënt eerst een binnenste tunnel naar B en draagt die tunnel dan binnen de buitenste naar A. A haalt de buitenste header weg, vindt een binnenste tunnel en stuurt die door zonder de sleutels te houden, dus de binnenste bescherming eindigt nog steeds bij B.

De uplink van de cliënt draagt dan twee lagen, terwijl het pad tussen A en B er één draagt. A ziet de buitenste adressen van de binnenste tunnel, wat genoeg is om te weten dat er verkeer is en ongeveer waar het heen gaat, en niet genoeg om de payload te lezen. Dat is het hele verschil met het seriële geval, en geen enkele hop-teller toont het. Wat A nog kan doen, is weigeren door te sturen wat het niet kan lezen, en dat staat de operator van die gateway altijd ter beschikking.

Nesting betaalt voor die eigenschap. Elke laag voegt header-overhead toe, dus MTU- en MSS-planning wordt verplicht in plaats van netjes, en een pad dat met één laag werkt, kan met twee grote pakketten stil laten vallen. Elke laag heeft ook eigen gedrag voor herverbinden en keepalive nodig, en een storing in één laag ziet er door de andere heen uit als een gedeeltelijke uitval.

Teken de waarnemers, niet alleen de tunnels

De tunnels zijn het makkelijke deel van de tekening. De waarnemers zijn waar het ontwerp over gaat, dus schrijf één rij per gezichtspunt en vul in wat elk echt kan lezen.

Twee rijen worden steeds verward: de operator van A en de leverancier van de tunnel van de cliënt. Ze kunnen één entiteit zijn, en aparte gateway-namen maken ze niet onafhankelijk. Onafhankelijk eigendom vereist aparte administratieve controle, aparte inloggegevens en aparte logging.

Metadata overleeft beide ontwerpen. Timing, pakketgroottes en verbindingsaantallen blijven bij elke hop waarneembaar, dus twee hops verhogen de kosten van correlatie in plaats van het signaal te verwijderen. Een ontwerp dat onzichtbaarheid belooft, moet tegen die lijst worden gecontroleerd voordat iemand erop vertrouwt.

Doorloop de faalpaden voordat u kiest

Breek dingen expres vanaf de cliënt, in de volgorde waarin een gebruiker ze zou tegenkomen. Begin met de interface en zijn MTU, want nesting faalt op pakketgrootte veel eerder dan op authenticatie.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Bevestig daarna de beschermingseindpunten in plaats van ze aan te nemen. Vraag de dienst om zijn certificaat van binnen de tunnel die open is, en vergelijk de keten die de cliënt ziet met de keten die de dienst werkelijk presenteert. Een gateway die opnieuw ondertekent of onderschept verandert dat certificaat, en de inspectie wordt in één commando zichtbaar.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Sluit af met de herverbindingsmatrix: de tunnel van de cliënt valt weg, die van B valt weg, het pad tussen A en B verandert. Noteer wat terugkomt en wat niet, en of een binnenste verbinding ooit terugvalt op een route buiten zijn bedoelde drager. Leg de adressen vast die elke test gebruikte, want herhaling op een ander toegangsnetwerk beantwoordt een andere vraag. Herhaal ook de MTU-proef na elke herverbinding, want een veranderd pad kan de bruikbare grootte verlagen zonder dat één configuratieregel beweegt.

Kies serieel wanneer A beleid op het binnenste pakket moet toepassen, of wanneer de cliënt geen twee gestapelde tunnels kan draaien. Kies nesting wanneer de binnenste payload bij A onleesbaar moet blijven. Schrijf de keuze op met zijn waarnemers en zijn MTU-cijfers, en de volgende persoon hoeft niet het hele plaatje opnieuw te tekenen om één vraag te beantwoorden.