Heeft de router tussen twee IPsec-peers IPsec nodig?
Een transitrouter stuurt de buitenste header door en ontsleutelt nooit. De eindpunten bezitten de IPsec-implementatie, en een simulator modelleert misschien geen van beide zoals u verwacht.
Een laboefening die zegt ‘configureer IPsec tussen twee sites’ verbergt twee verschillende taken. De twee eindpunten beëindigen de tunnel: ze onderhandelen, authenticeren, versleutelen en ontsleutelen. Elke router daartussen stuurt pakketten door waarvan de buitenste header bij de eindpunten hoort, en doet dat zonder te weten dat de tunnel bestaat.
Bepalen welke taak van een apparaat wordt gevraagd, is de eerste stap van de oefening. De meeste verwarring in labverslagen, en een flink deel van de verwarring in productiediagrammen, komt uit het behandelen van ‘ondersteunt IPsec’ als één eigenschap in plaats van twee.
Doorsturen is niet termineren
In tunnelmodus is de buitenste IP-header geadresseerd aan de apparaten die de tunnel termineren. Een router in het midden zoekt de bestemming op en stuurt door, precies zoals voor elk ander pakket, en de payload die hij draagt is ondoorzichtig voor hem.
Die ondoorzichtigheid is bewust. De router heeft het geheim van de peer niet, voert geen onderhandeling en heeft geen beleidsdatabase nodig. Hij heeft een route naar het verre eindpunt nodig en toestemming om het pakket door te sturen.
De twee verwarren leidt tot echte fouten: een transitfirewall vragen om ‘IPsec toe te staan’ terwijl de werkelijke eis is om protocol 50 tussen specifieke adressen toe te staan, of verwachten dat een tussenapparaat ontsleutelt voor inspectie terwijl het geen sleutel heeft.
Wat het tussenapparaat toch goed moet doen
Doorsturen heeft zijn eigen eisen. Routes moeten beide externe eindpunten bereiken, en elk beleid langs het pad moet het werkelijke buitenverkeer toestaan in plaats van een gegokt poortnummer. Een regel geschreven tegen TCP 443 omdat iemand TLS aannam, past niet op protocol 50.
Native ESP is IP-protocol 50. Het is geen TCP 50 en geen UDP 50, en een regel die niet-TCP-verkeer blokkeert, laat het vallen. Als het ontwerp UDP-inkapseling gebruikt, verandert het zichtbare transport naar de inkapselingspoort, en het beleid moet bij het gekozen ontwerp passen.
Pakketgrootte doet er ook toe. Een route die een kleine probe draagt, bewijst niet dat de volledige ingekapselde uitwisseling erin past. Een pad dat grote pakketten laat vallen, kan de onderhandeling laten slagen en de werkbelasting laten mislukken, wat op een applicatieprobleem lijkt. Test met verkeer ter grootte van de werkelijke werkbelasting voordat je de tunnel de schuld geeft.
Waarom de simulator de vraag verandert
Een simulator is geen router met een kortere functielijst; het is een model met een gedocumenteerde subset en zijn eigen regels over wat een bepaald apparaat geconfigureerd kan worden te doen. De Packet Tracer-FAQ van Cisco zegt expliciet dat apparaten en protocollen vereenvoudigde modellen zijn.
Zo wordt de vraag drie vragen. Stuurt het gesimuleerde apparaat de pakketten door die het scenario nodig heeft? Biedt hetzelfde apparaat het configuratieoppervlak dat de les veronderstelt? En betekent de geaccepteerde opdracht dat het gedrag echt wordt gesimuleerd, of alleen geparseerd?
Een ontbrekende opdracht kan een modellimiet zijn in plaats van een fout in je configuratie. Een aanwezige opdracht kan syntaxis accepteren zonder elk productiegedrag te reproduceren. Controleer de apparaathulp van de geïnstalleerde versie voordat je een conclusie trekt.
Een slaagvoorwaarde voor het lab schrijven
Voor een underlay-les is de slaagvoorwaarde bereikbaarheid van de eindpunten plus de buitenste pakketten die het tussenapparaat passeren. Bewijs het met de tellers van de simulator zelf of een pakketweergave, en noem het protocol dat je verwacht te zien.
Voor een IPsec-les voeg je de onderhandelingstoestand en één beschermde LAN-naar-LAN-stroom toe. Als de simulator beveiligingsassociaties toont, noteer ze dan. Als dat niet zo is, zeg dat dan in het verslag in plaats van te suggereren dat de tunnel is geverifieerd.
Bewaar de simulatorversie, de gekozen apparaten en het leerdoel bij het topologiebestand. Die registratie is wat iemand anders in staat stelt de oefening te reproduceren en te begrijpen welke delen zijn gemodelleerd.
Productieconfiguratie vereist zijn eigen platformbewijs. Een groen gesimuleerd pakket is een onderwijsresultaat, geen compatibiliteitsverklaring over de hardware die je gaat uitrollen.