Transport- eller tunneläge: avgör efter paketet, inte diagrammet
Transport och tunnel beskriver vad som finns inuti ESP, inte om en värd eller gateway är inblandad. Tre frågor avgör vilket läge en driftsättning behöver.
Läroboksdiagram kopplar transportläget till två värdar och tunnelläget till två gateways, och den tumregeln håller ända till den första driftsättning som bryter den. Läget beskriver vad ESP-paketet packar in, inte vilka parterna är. En gateway kan skydda trafik i transportläge, och ett par värdar kan använda tunnelläge om de väljer det. Tre frågor avgör vad en viss driftsättning behöver.
Läget är en layout, inte en topologi
I transportläge kommer ESP-huvudet efter IP-huvudet och före nästa lagers nyttolast, så det ursprungliga IP-huvudet blir utanför och synligt. I tunnelläge är det skyddade innehållet ett komplett IP-paket, och ett nytt yttre huvud namnger de två IPsec-parterna.
| Mode | What follows the outer IP header | Headers a capture shows |
|---|---|---|
| Transport | ESP, then the next-layer payload | One IP header |
| Tunnel | ESP, then a whole inner IP packet | Outer and inner headers |
När konfidentialitet väljs omfattar det skyddade området i tunnelläge det inre IP-huvudet, och därför kan en inspelning inte avslöja de verkliga slutpunkterna utan nycklar. Det yttre huvudet förblir läsbart i båda fallen, och det är just det som gör felsökning möjlig överhuvudtaget.
Fråga ett: vad finns exakt inuti ESP
Titta på paketet som applikationen producerar och fråga vilken gräns som skyddar det. Om svaret är transportnyttolasten mellan två redan korrekta adresser passar transportläget utan att hitta på ett extra huvud. Om det skyddade innehållet behöver egna adresser, eftersom de verkliga slutpunkterna skiljer sig från parterna som bär trafiken, gör tunnelläget jobbet. Båda fallen finns i samma organisation, och därför täcker en enda policyformulering sällan allt.
Den frågan kan besvaras med en inspelning och en routingtabell. Den kan inte besvaras med en teckning som kallar rutorna klient och server. En inspelning tagen hos endera parten visar inom sekunder vilken av de två du tittar på.
Fråga två: finns det redan en tunnel inuti
L2TP är det historiska motexemplet som visar poängen. Tjänsten bär PPP inuti en L2TP-session, och IPsec skyddar det utbytet; upplägget anger transportläge, med tunnelläge tillåtet som alternativ. Det synliga resultatet är en tunnel på tjänstenivå vars yttre skydd använder transportläge.
Så ordet tunnel i en produktbeskrivning säger ingenting om läget hos lagret under. Anteckna vilken fråga som avgjorde det, för nästa granskare kommer att fråga samma sak. Läs specifikationen för den kombinationen i stället för att resonera från namnet, för den vanan hindrar de flesta diskussioner om vad en produkt måste stödja.
Fråga tre: vad kräver parten
Två parter måste enas, och ett förslag som erbjuder ett läge medan den andra kräver det andra misslyckas under förhandlingen i stället för att försämras tyst. Fråga ägaren av den bortre änden vilket läge policyn namnger, och kontrollera förslaget i stället för dokumentationssammanfattningen.
Blandade miljöer är vanliga: en gateway avslutar transportlägessessioner för en äldre produkt och tunnellägessessioner för en platsförbindelse. Läget gäller per association, inte per enhet. Be om associationslistan i stället för funktionsnamnet, för namnet reser snabbare än konfigurationen.
Att läsa associationen som finns
För en granskning, lista parterna, läget, selektorerna och nästa lager protokoll, och lägg sedan till all inkapsling som är lindad runt resultatet. Adressöversättning lägger till sin egen yttre vy och är inte ett läge; ett översatt flöde kan fortfarande vara endera av de två. Listan är den enda artefakt som visar associationen som installerad och inte som avsedd.
Avsluta med frågan om routing och auktorisering, för en korrekt paketlayout säger ingenting om vilka subnät som är tillåtna eller om returvägen finns. De lever i policyn och i routingtabellen, och ingen av dem ändrar argumentet om läget.