Hvers vegna tcpdump sýnir IPsec-óbreyttan texta aðeins í eina átt

Þú keyrir tcpdump á ytri tengi Linux IPsec-gáttar og sérð tvo hluti í einu: innkomandi ESP-ramma og, rétt á eftir þeim, afkóðuðu innri pakkana. Út á við birtist aðeins ESP. Eðlilega ályktunin er að svör séu ekki send eða að IPsec dulriti aðra áttina og gleymi hinni. Hvorugt er satt.

Það sem þú ert að horfa á er handtökupunktur. Kjarninn umbreytir útleiðandi pökkum áður en sendingarleið tækisins afhendir þá pakkahylkinu, svo hylkið sér aldrei innra formið út á við. Á innleið er pakkinn fyrst tekinn sem ESP og afkóðaða afritið verður sýnilegt þegar hann fer aftur inn í staflann. Sama umferð, tveir mismunandi athugunargluggar.

Handtökupunkturinn ræður því hvað þú sérð

Á venjulegu tengi situr AF_PACKET-hylki nálægt tækjalaginu. Pakkar sem yfirgefa hýsilinn fara fyrst í gegnum IPsec-úttaksvinnslu, sem breytir innri TCP-hluta í ESP- eða UDP-4500-gagnastreng, og ná svo aðeins þessu lagi. Komandi pakkar eru afritaðir í hylkið þegar þeir koma af vírnum, enn dulritaðir, og afkóðaða niðurstaðan verður sýnileg síðar þegar staflinn afhendir hana á staðnum eða sendir hana áfram.

Sú röð skýrir ósamhverfuna að fullu. Þetta er ekki sönnun um stefnu, stefnu eða hegðun forrits, og að meðhöndla það sem slíkt sendir fólk að eltast við svar sem var allan tímann sent rétt. Þetta er ein af fáum netgátum þar sem tólið, ekki netið, skapar frávikið.

Lagaðu síuna að laginu sem þú átt við

Tjáning eins og tcp port 443 velur innri TCP-tengingu. Út á við hefur sú tenging þegar orðið ESP þegar hylkið er spurt, svo sían passar við ekkert. Ef þú vilt telja verndaða umferð skaltu sía eftir ytra forminu í staðinn: prótókoll 50 fyrir hrátt ESP, eða UDP-port 4500 þegar NAT-för er í gangi. Báðar síur gefa pakkafjölda sem hægt er að bera saman milli hópanna tveggja, sem er venjulega ástæðan fyrir talningunni. Hvorug segir þér hvort innri beiðninni var svarað.

Ekki meðhöndla UDP 4500-fjölda sem fjölda ESP-pakka. IKE notar einnig þetta port fyrir NAT-T lífvarðarskilaboð og fyrir umbúðaða skiptinguna, svo talan inniheldur umferð sem er ekki gögnin sem þú vildir mæla. Upphaflega IKE-skiptingin á UDP 500 þarf sína eigin síu ef það er spurningin. Tala sem blandar stjórnumferð saman við gögn gerir einnig allar bandvíddaráætlanir rangar um óþekkt frame. Aðskildar talningar svara aðskildum spurningum.

Skrifaðu síuna við hlið spurningarinnar sem hún svarar. „Hve mikið ESP fór úr kassanum“ og „fór vefbeiðnin úr kassanum“ eru mismunandi mælingar með mismunandi síum, og ein handtaka getur ekki leyst bæði. Án þessarar athugasemdar munu tveir einstaklingar bera saman tölur sem voru aldrei að telja sama hlutinn.

Fylgstu með fyrir umbreytinguna, ekki eftir

Ef þú þarft að sjá útleiðandi óbreyttan texta skaltu færa athugunarpunktinn fyrr, fyrir IPsec-úttaksvinnsluna. NFLOG gefur þér Netfilter-króka þar sem regla getur afritað valda pakka í hylki í notendarými, sem tcpdump getur lesið. Leiðarvísir strongSwan um umferðardump skjalfestir þessa aðferð einmitt af þessari ástæðu.

Stefnusamsvörunin takmarkar regluna við umferð sem er að fara inn í göng. -m policy --pol ipsec --dir out er það sem gerir regluna nákvæma í stað þess að skrá hvern pakka sem kassinn sendir. Lestu síðan logghópinn með takmarkaðri handtöku: lítill fjöldi skyndimynda og stærðarmörk koma í veg fyrir að greiningin verði að umferðarsafni. Takmörkuð handtaka er líka auðveldari að afhenda rýni án þess að draga með sér óviðkomandi hleðslu. Ákveddu fjöldann áður en þú byrjar, ekki eftir að þú sér hve mikið kom.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Veldu krókann sem passar við flæðið. OUTPUT nær yfir umferð sem gáttin býr sjálf til; gegnumferð frá LAN-biðlara fer í gegnum FORWARD-keðjuna í staðinn, og regla á OUTPUT mun aldrei sjá hana. Slóðin og portið hér að ofan eru staðgenglar fyrir samþykktar prófunarviðtak.

Hvað sannar athugunin

NFLOG er skráningarmark, ekki samþykkisákvörðun. Pakki sem birtist þar sýnir að hann náði krókanum og passaði við regluna. Það sýnir ekki að síðari sía hafi leyft hann, að tækið hafi sent hann eða að jafninginn hafi fengið eitthvað.

Tómt logg er jafn tvírætt. Athugaðu pakkatalningu reglunnar, staðfestu stefnuna, staðfestu að flæðið hafi raunverulega passað við IPsec-stefnu og staðfestu viðtakið. Aðeins samhljóma talning á báðum jafningjum gerir athugun að ályktun. Berðu síðan saman talningar öryggjabandalagsins á báðum jafningjum fyrir sömu stýrðu tilraun, því SA-talningarnar eru hið réttmæta skrá um hvað var varið og sent.

Ein gildra enn: „óbreyttur texti“ þýðir hér utan IPsec-dulritunarlagsins. Innri HTTPS-lota hefur enn sína eigin TLS. Að grípa afkóðaða pakkann afkóðar ekki TLS forritsins, og að sjá læsilegt HTTP þar þýðir að forritið notaði aldrei HTTPS.

Hreinsaðu og berðu saman báða enda

Fjarlægðu nákvæmlega þá reglu sem þú settir inn, eftir eiganda hennar, um leið og athuguninni lýkur. Að skilja skráningarreglu eftir kostar CPU á hverjum samsvarandi pakka og skapar hljóðlega vandamál með varðveislu gagna. Eyðaðu með því að endurtaka regluna með -D í stað þess að skola keðju sem þú átt ekki.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Ef uppsetningin notar IPsec í notendarými, XFRM-tengi eða vélbúnaðarafhleðslu færast athugunarpunktarnir og þessi uppskrift gildir kannski alls ekki. Með libipsec er skjalfesti staðurinn til að fylgjast með innri umferð TUN-tækið. Greindu leiðina fyrst, veldu síðan punktinn sem svarar spurningunni, og búðu þig við að stefnurnar tvær líti aðeins mismunandi út þegar þú horfir á ranga hlið umbreytingarinnar.