Ĉu la enkursigilo inter du IPsec-partneroj bezonas IPsec?

Laboratoria ekzerco, kiu diras „agordu IPsec inter du retejoj“, kaŝas du malsamajn taskojn. La du finpunktoj finas la tunelon: ili intertraktas, aŭtentikigas, ĉifras kaj malĉifras. Ĉiu enkursigilo intere plusendas paketojn, kies ekstera kaplinia apartenas al la finpunktoj, kaj ĝi faras tion sen scii, ke la tunelo ekzistas.

Decidi, kiun taskon oni petas de aparato, estas la unua paŝo de la ekzerco. La plej granda parto de la konfuzo en laboratoriaj raportoj, kaj bona parto de la konfuzo en produktadaj diagramoj, venas de tio, ke „subtenas IPsec“ estas traktata kiel unu eco anstataŭ du.

Plusendo ne estas finigo

En tunela reĝimo, la ekstera IP-kaplinia estas adresita al la aparatoj, kiuj finas la tunelon. Enkursigilo en la mezo serĉas la cellokon kaj plusendas, ĝuste kiel por iu ajn alia paketo, kaj la ŝarĝo, kiun ĝi portas, estas maldiafana por ĝi.

Tiu maldiafaneco estas intenca. La enkursigilo ne havas la sekreton de la partnero, ne faras intertraktadon, kaj ne bezonas politikan datumbazon. Ĝi bezonas itineron al la malproksima finpunkto kaj permeson plusendi la paketon.

Konfuzi la du aferojn kondukas al realaj eraroj: peti trapasan fajromuron „permesi IPsec“, kiam la vera postulo estas permesi protokolon 50 inter difinitaj adresoj, aŭ atendi, ke meza aparato malĉifros por inspektado, kiam ĝi havas neniun ŝlosilon.

Kion la meza aparato tamen devas fari ĝuste

Plusendo havas proprajn postulojn. Itineroj devas atingi ambaŭ eksterajn finpunktojn, kaj ĉiu politiko laŭ la vojo devas permesi la realan eksteran trafikon anstataŭ divenitan pordan numeron. Regulo skribita kontraŭ TCP 443 ĉar iu supozis TLS ne kongruos kun protokolo 50.

Denaska ESP estas IP-protokolo 50. Ĝi ne estas TCP 50 kaj ne UDP 50, kaj regulo, kiu blokas ne-TCP-trafikon, forĵetos ĝin. Se la dezajno uzas UDP-enkapsuligon, la videbla transporto ŝanĝiĝas al la enkapsuliga pordo, kaj la politiko devas kongrui kun la elektita dezajno.

Ankaŭ la paketa grando gravas. Itinero, kiu portas malgrandan sondilon, ne pruvas, ke la tuta enkapsuligita interŝanĝo eniras. Vojo, kiu forĵetas grandajn paketojn, povas lasi la intertraktadon sukcesi kaj la laborŝarĝon malsukcesi, kio aspektas kiel aplikaĵa problemo. Testu per trafiko de la grando de la reala laborŝarĝo antaŭ ol kulpigi la tunelon.

Kial la simulatoro ŝanĝas la demandon

Simulatoro ne estas enkursigilo kun pli mallonga funkciolisto; ĝi estas modelo kun dokumentita subaro kaj propraj reguloj pri tio, kion difinita aparato povas esti agordita fari. La Oftaj Demandoj de Cisco Packet Tracer klare diras, ke aparatoj kaj protokoloj estas simpligitaj modeloj.

Do la demando fariĝas tri demandoj. Ĉu la simulita aparato plusendas la paketojn, kiujn la scenaro bezonas? Ĉu la sama aparato ofertas la agordan surfacon, kiun la leciono supozas? Kaj ĉu la akceptita komando signifas, ke la konduto estas vere simuliata, aŭ nur sintakse analizata?

Mankanta komando povas esti modellimo anstataŭ eraro en via agordo. Ĉeestanta komando povas akcepti sintakson sen reprodukti ĉiun produktadan konduton. Kontrolu la aparatan helpon de la instalita versio antaŭ ol konkludi en iu ajn direkto.

Skribi trapasan kondiĉon por la laboratorio

Por underlay-leciono, la trapasa kondiĉo estas atingeblo de la finpunktoj plus la eksteraj paketoj, kiuj trapasas la mezan aparaton. Pruvu tion per la propraj nombriloj de la simulatoro aŭ per paketa vido, kaj nomu la protokolon, kiun vi atendas vidi.

Por IPsec-leciono, aldonu la intertraktadan staton kaj unu protektitan fluon de LAN al LAN. Se la simulatoro montras sekurecajn asociojn, registru ilin. Se ne, diru tion en la raporto anstataŭ sugesti, ke la tunelo estis kontrolita.

Konservu la simulatoran version, la elektitajn aparatojn kaj la lernocelon kune kun la topologia dosiero. Ĝuste tiu registro ebligas al iu alia ripeti la ekzercon kaj kompreni, kiuj partoj estis modelitaj.

Produkta agordo bezonas proprajn platformajn pruvojn. Verda simulita paketo estas instrua rezulto, ne deklaro pri kongruo kun la aparataro, kiun vi deplojos.