L2TP, GRE of IPsec: welke laag moet de sessie dragen?

Twee vragen raken verstrengeld zodra L2TP, GRE en IPsec in dezelfde ontwerpnotitie belanden: welke sessie draag ik, en welke laag beschermt die? Is de eerste verkeerd, dan blijft alles stroomafwaarts intern consistent terwijl het verkeerde probleem wordt opgelost — een gerouteerde overlay waar gebruikers moesten inbellen, of een inbelconcentrator die een site-to-site-gateway vervangt. Het werkblad hieronder dwingt dat onderscheid af voordat iemand op een apparaat inlogt. Vul het in volgorde in en elke regel wordt iets dat je afzonderlijk kunt testen.

Begin bij de sessie, niet bij de protocollenlijst

Een externe gebruiker met een PPP-sessie en een gerouteerde overlay tussen twee gateways zijn verschillende netwerkrelaties, zelfs wanneer beide uiteindelijk in IPsec worden verpakt. De eerste beëindigt een verbinding per gebruiker en vereist adresuitgifte, authenticatie van een persoon of apparaat, en een beleid dat benoemt welke interne netwerken die gebruiker mag bereiken. De tweede stuurt pakketten tussen locaties waar niemand naartoe inbelt.

Schrijf één zin die benoemt welke van de twee je bouwt, en lees die terug alsof je de persoon bent die hem moet beheren. Als de zin het woord 'en' nodig heeft, bouw je beide, en het werkblad heeft twee kolommen nodig in plaats van één compromiskolom die elk half dient. Als hij een gebruiker noemt maar geen adrespool, of een prefix maar geen doorstuurbeleid, is de zin nog onvolledig. De formulering klinkt bureaucratisch, maar het is de goedkoopste plek om een ontwerp te vangen dat anders via een helpdeskticket wordt ontdekt.

Geef elke laag precies één taak

L2TPv2 draagt PPP-sessies tussen zijn twee eindpunten. PPP doet de linkonderhandeling en, wanneer die wordt onderhandeld, de gebruikerauthenticatie; L2TP voegt geen cryptografie toe, dus een kale L2TP-daemon implementeert niets van de IPsec-beveiligingsrelatie en hoort alleen binnen een link die je al vertrouwt.

GRE is een inkapseling tussen twee adressen. Het draagt pakketten van de netwerklaag over een logische overlay en biedt op zichzelf noch vertrouwelijkheid noch een geauthenticeerde peer-identiteit. Dat is geen defect: de header is eenvoudig ontworpen zodat hij op doorstuurhardware goedkoop blijft te verwerken. Het gevolg is dat GRE de vraag 'hoe verplaats ik dit pakket tussen twee adressen' beantwoordt en niets anders — precies de vraag die je hem moet stellen.

Daarmee blijft IPsec over als de laag die verkeer selecteert, de peers authenticeert en versleutelt wat hem is opgedragen te beschermen. Welk verkeer het beschermt, is een configuratiebeslissing die moet passen bij de inkapseling die de eindpunten daadwerkelijk genereren, want een beleid voor het buitenste GRE-adres gedraagt zich anders dan een voor de binnenste prefixen. De GRE-specificatie houdt payload, GRE-header en buitenste transportprotocol zichtbaar gescheiden, en je beleid heeft dezelfde scheiding nodig.

Schrijf het pakketpad vóór de configuratie

Neem één pakket en som elke header op die wordt toegevoegd, in de volgorde waarin dat gebeurt, met het apparaat dat hem toevoegt. Voor een inbelgebruiker is dat meestal PPP in L2TP in IPsec; voor een site-overlay het binnenste IP-pakket in GRE in IPsec. Als twee apparaten dezelfde header toevoegen, heb je een lus of een dubbele tunnel, en geen enkele beleidswijziging lost dat op.

Dezelfde lijst bepaalt de MTU, want de bruikbare binnenmaat is de gemeten pad-MTU minus de headers die je zojuist hebt opgesomd en niets anders. Neem geen getal over uit een forumbericht: tel de overhead van buitenste IP, UDP en ESP op, dan GRE of L2TP, dan PPP waar van toepassing, en trek dat af van de pad-MTU die je echt hebt gemeten. Symptomen die alleen bij grote overdrachten optreden, of sessies die opkomen en dan sterven op het eerste grote antwoord, leiden meestal terug naar die optelling die op de gok is gedaan.

Controleer elke laag afzonderlijk, van buiten naar binnen

Voer de controles in volgorde uit en stop bij de eerste die faalt. Elke regel beantwoordt een andere vraag, dus een fout wijst naar één kolom van het werkblad in plaats van te zeggen dat de tunnel stuk is.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Op een Cisco-box is het equivalent rolspecifiek, en de exacte syntaxis hangt af van platform en release: show crypto session voor de IPsec-peers, interfacetellers voor de GRE- of tunnelinterface, en de VPDN- of PPP-verificatie voor de inbelrol. Een commandoset die PPP beëindigt, bewijst niets over GRE-ondersteuning, en een werkende GRE-interface bewijst niets over de PPP-dienst, dus verifieer de rol die je werkelijk hebt geconfigureerd in plaats van die in het diagram.

Noteer elke uitvoer naast de werkbladregel waar hij bij hoort. Aantekeningen die tijdens de storing worden gemaakt, zijn meer waard dan een topologie die achteraf uit het geheugen opnieuw wordt getekend.

Orden het afbreken en verifieer daarna opnieuw

Het afbreken gebeurt met een reden in omgekeerde volgorde: haal het beschermde verkeer uit het IPsec-beleid voordat je de inkapseling verwijdert waarvoor het is geschreven, anders blijft het beleid wijzen naar een interface die niet meer bestaat en faalt de volgende configuratielading ergens dat los lijkt te staan. Op Linux betekent dat de state- en policy-items verwijderen vóór de tunnelinterface; op een router het crypto-map- of profile-item verwijderen vóór de tunnel.

Herhaal na de herbouw de vier acceptatieobservaties één voor één: buitenste bereikbaarheid, een opgezette IPsec-associatie, een opgezette PPP-sessie waar het ontwerp er een bevat, en binnenste doorsturing naar een echt bestemmingsadres. Eén groen licht is geen bewijs voor de andere drie, en die kloof is de fout die in productie het langst overleeft — een tunnel die omhoog staat, versleuteld is en niets doorstuurt omdat de binnenste route nooit is toegevoegd.

Bewaar het ingevulde werkblad naast de apparaatconfiguratie. Elke kolom die je niet kunt invullen is een laag zonder toegewezen taak, en een laag zonder toegewezen taak is meestal een laag die niet in de stack hoort.