IPsec ESP: ko tas pārnēsā un kā pierādīt, ka tas plūst
ESP tuneļa režīmā ietver iekšēju IP paketi un identificē savu asociāciju ar SPI. Izlasiet stāvokli un pēc tam vērojiet, kā viena plūsma kustina skaitītājus.
ESP pārnēsā trafiku IPsec VPN, un tā runbook sākas ar vienu noteikumu: izlasiet drošības asociāciju, pirms maināt politiku. Lielākā daļa neizskaidrojamās ESP uzvedības atgriežas pie selektora, kas nesaskaņojās, režīma, kas tika pieņemts, nevis nolasīts, vai skaitītāja, ko neviens nepārbaudīja, kamēr tika sūtīta viena plūsma. Trīs soļi zemāk nosaka, kas ko pārnēsā, pierāda, ka viena plūsma to izmanto, un atstāj atritināšanu, kas nav atkarīga no atmiņas. Katrs solis dod vienu novērojumu, ko ir vērts pierakstīt.
Ziniet laukus, pirms tos lasāt
ESP liek galveni pirms aizsargātajiem datiem un asti aiz tiem. Galvene nes drošības parametru indeksu, kas nosaka, kuru asociāciju uztvērējam jāizmanto, secības numuru atkārtojumu noteikšanai, bet astē – polsterējumu, kas notur lietderīgo slodzi šifram izlīdzinātu. Astes nākamās galvenes lauks pasaka, kas ir aizsargātais saturs, un tā uztvērējs zina, ko tas atšifrēja.
Režīms maina to, kas atrodas šīs aizsardzības iekšpusē. Tuneļa režīmā aizsargātais materiāls ir pilnīgs iekšējs IP pakets, un jauna ārējā galvene to pārnēsā starp galapunktiem. Transporta režīmā aizsardzība ietver esoša paketa augšējā slāņa lietderīgo slodzi, tāpēc nav otras IP galvenes, ko atvērt. Kurš režīms tiek izmantots, ir konfigurācijas fakts, nevis interpretācijas jautājums. Lasiet to no stāvokļa ieraksta, nevis seciniet no diagrammas.
Neviens režīms neslēpj ārējo adresāciju, kurai pakets jānogādā. Tā ir dizaina īpašība, nevis trūkums, un tāpēc starpnieks novērotājs joprojām redz, kuras divas adreses sarunājas, pat ja lietderīgā slodze ir necaurredzama.
Pirmais solis: izlasiet stāvokli, pēc tam politiku
Stāvokļa ieraksti tur atslēgas un skaitītājus; politikas ieraksti tur selektorus, kas izlemj, kam tos drīkst izmantot. Linux abi ir redzami bez paketu uztveršanas, un lasīšana šādā secībā notur divus jautājumus atsevišķi.
ip xfrm state
ip xfrm policyStāvokļa izvadē pārbaudiet asociācijas avotu un galamērķi, režīmu un to, vai iekapsulēšana rāda UDP portus. Šie porti nozīmē, ka tiek izmantota NAT caureja, kas maina to, kas starpniekam ugunsmūrim jāatļauj, bet ne to, kuri selektori vai atslēgas ir spēkā galapunktos.
Pēc tam izlasiet politikas selektorus. Selektors, kas nosauc šaurāku prefiksu nekā pārbaudāmais trafiks, ir visbiežākais iemesls, kāpēc strādājošs tunelis šķietami ignorē plūsmu, un nepareiza protokola selektors dod tādu pašu klusumu.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
Ražotāju rīki izdrukā to pašu informāciju ērtākā formā. ipsec statusall strongSwan tas uzskaita bērnasociācijas, to selektorus un baitu skaitītājus, kas bieži ir ātrāk nekā lasīt neapstrādātu xfrm izvadi, ja jau zināt, uz kuru bērnu skatīties.
Otrais solis: pierādiet, ka viena plūsma kustina skaitītājus
Skaitītājiem ir jēga tikai tad, ja zināt, kam tie bija jākustina, tāpēc izvēlieties avotu un galamērķi, ko selektors noteikti aptver, un nosūtiet vienu nekaitīgu pieprasījumu. Pēc tam vēlreiz izlasiet to pašu ierakstu un salīdziniet.
ip -s xfrm state
tcpdump -ni any espDivi nolasījumi stāsta dažādus stāstus. Paketes, kas pieaug izejošajā pusē, bet nekad ienākošajā, norāda uz pārsūtīšanas vai atgriešanās ceļa problēmu, nevis atslēgas problēmu, jo pakete tika iekapsulēta un aizgāja. Ja nekustas neviens skaitītājs, trafiks nekad nav atbildis politikai, un selektors ir vieta, kur skatīties.
Uztveršana tajā pašā solī apstiprina iekapsulēšanu uz vada, tostarp to, vai ārējās paketes ir ESP vai UDP iekapsulēts ESP. Tā arī parāda adreses, kas patiešām pārnēsāja plūsmu, un tās dažkārt atšķiras no tām, kas bija lasītajā konfigurācijā.
Trešais solis: mainiet vienu lietu un saglabājiet atritināšanu
Pierakstiet asociācijas avotu, galamērķi, režīmu, selektorus un skaitītājus, pirms kaut ko rediģējat. Ja izmaiņas padara situāciju sliktāku, tieši šis pieraksts ļauj atjaunot iepriekšējo stāvokli, nevis no jauna būvēt strādājošu konfigurāciju no minējuma. Pieraksts aizņem minūti un ietaupa stundu vēlāk. Tas ir arī vienīgais artefakts, kas pārdzīvo cilvēku, kurš veica izmaiņas.
Mainiet vienu selektoru vai vienu parametru, ielādējiet to no jauna un atkārtojiet otro soli tai pašai plūsmai. Asociācijas dzēšana sagrauj katru plūsmu, kas to izmanto, tāpēc mērķēta rediģēšana un bērna atkārtota ielāde gandrīz vienmēr ir labāka par stāvokļa iztīrīšanu, lai redzētu, kas notiks.
Selektora rediģēšanas atritināšana ir iepriekšējās politikas atjaunošana un atkārtota ielāde, ar nosacījumu, ka partnerim var būt vajadzīga atbilstoša izmaiņa, ja selektors tiek apspriests, nevis ir lokāls. Pierakstiet šo atkarību, kamēr tā ir svaiga, jo puslīdz atjaunotu pāri ir grūtāk pārdomāt nekā jebkuru no diviem gala stāvokļiem.
Visbeidzot, turiet apjomu godīgu. Plūstoša ESP asociācija pierāda, ka divi vārteji aizsargā un piegādā segmentu, un tā neko nesaka par to, vai programma virsū autentificē savus lietotājus vai šifrē to, ko glabā. Tie ir atsevišķi kontroles ar atsevišķiem pierādījumiem, un runbook ir pabeigts tikai tad, kad nākamais cilvēks var to atkārtot no pierakstiem.