ESP dra die verkeer in ’n IPsec-VPN, en ’n runbook daarvoor begin met een reël: lees die sekuriteitsassosiasie voordat jy ’n beleid verander. Die meeste onverklaarbare ESP-gedrag kom van ’n selektor wat nie ooreengestem het nie, ’n modus wat aangeneem is eerder as gelees, of ’n teller wat niemand nagegaan het terwyl ’n enkele stroom gestuur is nie. Die drie stappe hieronder stel vas wat wat dra, bewys dat een stroom dit gebruik, en laat ’n terugrol wat nie van geheue afhang nie. Elke stap lewer een waarneming wat die moeite werd is om neer te skryf.

Ken die velde voordat jy dit lees

ESP plaas ’n kop voor die beskermde data en ’n sleepwa agter dit. Die kop dra ’n sekuriteitsparameterindeks wat identifiseer watter assosiasie die ontvanger moet gebruik, ’n volgordenommer vir herspelopsporing, en opvulling in die sleepwa wat die loonvrag vir die syfer in lyn hou. Die volgende-kop-veld in die sleepwa sê wat die beskermde inhoud is, en dit is hoe die ontvanger weet wat hy gedekapsuleer het.

Die modus verander wat binne daardie beskerming sit. In tonnelmodus is die beskermde materiaal ’n volledige binneste IP-pakket, en ’n nuwe buitenste kop dra dit tussen die eindpunte. In vervoermodus omhul die beskerming die boonste-laag-loonvrag van ’n bestaande pakket, dus is daar geen tweede IP-kop om oop te maak nie. Watter modus gebruik word, is ’n feit van die konfigurasie, nie ’n saak van interpretasie nie. Lees dit uit die toestandinskrywing eerder as om dit uit ’n diagram af te lei.

Geen van die twee modusse verberg die buitenste adressering wat die pakket moet aflewer nie. Dit is ’n eienskap van die ontwerp eerder as ’n tekortkoming, en dit is waarom ’n tussenliggende waarnemer steeds kan sien watter twee adresse praat selfs wanneer die loonvrag onduidelik is.

Stap een: lees die toestand, dan die beleid

Die toestandinskrywings hou die sleutels en tellers; die beleidsinskrywings hou die selektore wat bepaal wat hulle mag gebruik. Op Linux is albei sigbaar sonder ’n pakketopname, en om hulle in daardie volgorde te lees hou die twee vrae apart.

ip xfrm state
ip xfrm policy

Kyk in die toestanduitset na die bron en bestemming van die assosiasie, die modus, en of die inkapseling UDP-paaie wys. Daardie paaie beteken NAT-deurgang word gebruik, wat verander wat ’n tussenliggende vuurmuur moet toelaat, maar nie watter selektore of sleutels by die eindpunte geld nie.

Lees dan die selektore in die beleid. ’n Selektor wat ’n nouer voorvoegsel noem as die verkeer wat jy toets, is die algemeenste rede waarom ’n werkende tonnel ’n stroom blyk te ignoreer, en ’n selektor vir die verkeerde protokol lewer dieselfde stilte.

FieldWhere it appearsWhat it decides
Security parameter indexESP header, and the receiving state entryWhich association and keys the receiver applies
Sequence numberESP headerReplay detection for that association
Next headerESP trailerWhat the decapsulated payload contains
Inner IP headerInside tunnel-mode payload onlyThe original source and destination the endpoints act on
Traffic selectorsPolicy, not the packetWhich local traffic is allowed to use the association

Leveranciersgereedskap druk dieselfde inligting in ’n vriendeliker vorm. ipsec statusall op strongSwan lys die kindassosiasies, hul selektore en hul greptellers, wat dikwels vinniger is as om rou xfrm-uitset te lees wanneer jy al weet watter kind om na te kyk.

Stap twee: bewys dat een stroom die tellers beweeg

Tellers is net betekenisvol as jy weet wat hulle moes beweeg het, so kies ’n bron en bestemming wat die selektor beslis dek en stuur een onskadelike versoek. Lees dan dieselfde inskrywing weer en vergelyk.

ip -s xfrm state
tcpdump -ni any esp

Twee lesings vertel verskillende verhale. Pakkette wat aan die uitgaande kant toeneem maar nooit aan die inkomende kant nie, dui op ’n aanstuur- of terugpadprobleem eerder as ’n sleutelprobleem, want die pakket is ingekapsel en het vertrek. Nie een teller wat beweeg nie beteken die verkeer het nooit die beleid gepas nie, en die selektor is waar om te kyk.

Die opname in dieselfde stap bevestig die inkapseling op die draad, insluitend of die buitenste pakkette ESP of UDP-ingekapselde ESP is. Dit wys ook vir jou die adresse wat werklik die stroom gedra het, wat soms verskil van diegene in die konfigurasie wat jy gelees het.

Stap drie: verander een ding en hou ’n terugrol

Teken die assosiasie se bron, bestemming, modus, selektore en tellers aan voordat jy enigiets wysig. As ’n verandering dinge erger maak, is daardie rekord wat jou in staat stel om die vorige toestand te herstel eerder as om ’n werkende konfigurasie uit ’n raaiskoot te herbou. Daardie rekord neem ’n minuut om te skryf en spaar ’n uur later. Dit is ook die enigste artefak wat die persoon wat die verandering gemaak het, oorleef.

Verander een selektor of een parameter, herlaai dit, en herhaal stap twee teen dieselfde stroom. Om ’n assosiasie te verwyder breek elke stroom wat dit gebruik af, dus is ’n gerigte wysiging en ’n herlaai van die kind byna altyd beter as om toestand te spoel om te sien wat gebeur.

Terugrol vir ’n selektorewysiging is om die vorige beleid te herstel en te herlaai, met die voorbehoud dat die eweknie ’n ooreenstemmende verandering mag nodig hê as die selektor onderhandel word eerder as plaaslik. Skryf daardie afhanklikheid neer terwyl dit vars is, want ’n half-herstelde paar is moeiliker om te beredeneer as enige van die twee eindtoestande.

Laastens, hou die omvang eerlik. ’n Vloeiende ESP-assosiasie bewys die twee poorte beskerm en lewer die segment, en dit sê niks oor of die toepassing bo-op sy gebruikers verifieer of wat hy stoor, versleutel nie. Dit is aparte kontroles met aparte bewyse, en die runbook is eers klaar wanneer die volgende persoon dit uit die notas kan herhaal.

Verwante artikels