Behöver routern mellan två IPsec-peers IPsec?

En laborationsövning som säger ”konfigurera IPsec mellan två platser” döljer två olika arbeten. De två ändpunkterna avslutar tunneln: de förhandlar, autentiserar, krypterar och dekrypterar. Varje router däremellan vidarebefordrar paket vars yttre huvud tillhör ändpunkterna, och den gör det utan att veta att tunneln finns.

Att avgöra vilket arbete en enhet ombeds utföra är övningens första steg. Merparten av förvirringen i laborationsrapporter, och en god del av förvirringen i produktionsdiagram, kommer av att behandla ”stöder IPsec” som en egenskap i stället för två.

Vidarebefordran är inte avslut

I tunneläge är det yttre IP-huvudet adresserat till de enheter som avslutar tunneln. En router i mitten slår upp destinationen och vidarebefordrar, precis som för vilket annat paket som helst, och nyttolasten den bär är ogenomtränglig för den.

Den ogenomträngligheten är avsiktlig. Routern har inte peerens hemlighet, kör ingen förhandling och behöver ingen policydatabas. Den behöver en rutt mot den avlägsna ändpunkten och tillstånd att vidarebefordra paketet.

Att blanda ihop de två leder till verkliga fel: att be en transitbrandvägg att ”tillåta IPsec” när det faktiska kravet är att tillåta protokoll 50 mellan specifika adresser, eller att förvänta sig att en mellanenhet dekrypterar för inspektion när den inte har någon nyckel.

Vad mellanenheten ändå måste få rätt

Vidarebefordran har sina egna krav. Rutter måste nå båda de externa ändpunkterna, och varje policy längs vägen måste tillåta den faktiska yttre trafiken i stället för ett gissat portnummer. En regel skriven mot TCP 443 eftersom någon antog TLS kommer inte att matcha protokoll 50.

Inbyggd ESP är IP-protokoll 50. Det är inte TCP 50 och inte UDP 50, och en regel som blockerar icke-TCP-trafik släpper det. Om designen använder UDP-inkapsling ändras den synliga transporten till inkapslingsporten, och policyn måste matcha den valda designen.

Paketstorleken spelar också roll. En rutt som bär en liten sond bevisar inte att hela det inkapslade utbytet får plats. En väg som släpper stora paket kan låta förhandlingen lyckas och arbetsbelastningen misslyckas, vilket ser ut som ett applikationsproblem. Testa med trafik i storlek av den verkliga arbetsbelastningen innan du skyller på tunneln.

Varför simulatorn ändrar frågan

En simulator är inte en router med kortare funktionslista; den är en modell med en dokumenterad delmängd och sina egna regler för vad en viss enhet kan konfigureras att göra. Ciscos Packet Tracer-FAQ säger uttryckligen att enheter och protokoll är förenklade modeller.

Så blir frågan tre frågor. Vidarebefordrar den simulerade enheten de paket som scenariot behöver? Erbjuder samma enhet den konfigurationsyta som lektionen förutsätter? Och betyder det accepterade kommandot att beteendet verkligen simuleras, eller bara tolkas?

Ett saknat kommando kan vara en modellbegränsning snarare än ett fel i din konfiguration. Ett befintligt kommando kan acceptera syntax utan att återge alla produktionsbeteenden. Kontrollera enhetshjälpen för den installerade versionen innan du drar någon slutsats.

Att skriva ett godkännandekriterium för labben

För en underlay-lektion är godkännandekriteriet att ändpunkterna nås plus de yttre paketen som passerar mellanenheten. Bevisa det med simulatorns egna räknare eller en paketvy, och namnge det protokoll du förväntar dig att se.

För en IPsec-lektion lägger du till förhandlingstillståndet och ett skyddat LAN-till-LAN-flöde. Om simulatorn visar säkerhetsassociationer, registrera dem. Om inte, säg det i rapporten i stället för att antyda att tunneln verifierades.

Behåll simulatorversionen, de valda enheterna och lärandemålet tillsammans med topologifilen. Det är den dokumentationen som gör att någon annan kan återskapa övningen och förstå vilka delar som modellerades.

Produktionskonfiguration behöver sina egna plattformsbevis. Ett grönt simulerat paket är ett undervisningsresultat, inte ett kompatibilitetsuttalande om den hårdvara du kommer att driftsätta.