Miksi tcpdump näyttää IPsecin selkokieltä vain yhteen suuntaan

Ajat tcpdumpia Linuxin IPsec-yhdyskäytävän ulkorajapinnalla ja näet kaksi asiaa kerralla: saapuvat ESP-kehykset ja heti niiden jälkeen salatut sisäiset paketit. Lähtevään suuntaan näkyy vain ESP. Luonteva johtopäätös on, ettei vastauksia lähetetä tai että IPsec salaa toisen suunnan ja unohtaa toisen. Kumpikaan ei pidä paikkaansa.

Se, mitä katselet, on kaappauspiste. Ydin muuntaa lähtevät paketit ennen kuin laitteen lähetyspolku antaa ne pakettisocketille, joten socket ei koskaan näe lähtevää sisäistä muotoa. Saapuva paketti kaapataan ensin ESP:nä ja purettu kopio tulee näkyviin, kun se palaa pinon sisään. Sama liikenne, kaksi eri tarkkailuikkunaa.

Kaappauspiste päättää, mitä näet

Tavallisella rajapinnalla AF_PACKET-socket sijaitsee lähellä laitekerrosta. Isännän jättävät paketit kulkevat ensin IPsecin lähtökäsittelyn läpi, joka muuttaa sisäisen TCP-segmentin ESP- tai UDP-4500-datagrammiksi, ja saapuvat vasta sitten tälle kerrokselle. Saapuvat paketit kopioidaan socketiin niiden tullessa johdosta, yhä salattuina, ja purettu tulos tulee näkyviin myöhemmin, kun pino toimittaa sen paikallisesti tai välittää sen eteenpäin.

Tuo järjestys selittää epäsymmetrian täysin. Se ei ole todiste suunnasta, käytännöstä tai sovelluksen käyttäytymisestä, ja sellaisena käsitteleminen lähettää ihmiset jahtaamaan vastausta, joka oli koko ajan lähetetty oikein. Se on yksi harvoista verkon arvoituksista, joissa väline, ei verkko, luo poikkeaman.

Sovita suodatin kerrokseen, jota tarkoitat

Lauseke kuten tcp port 443 valitsee sisäisen TCP-yhteyden. Lähtevässä suunnassa yhteys on jo muuttunut ESP:ksi, kun socketilta kysytään, joten suodatin ei vastaa mitään. Jos haluat laskea suojattua liikennettä, suodata sen sijaan ulkoisen muodon mukaan: protokolla 50 raa'alle ESP:lle tai UDP-portti 4500, kun NAT-läpäisy on pelissä. Molemmat suodattimet antavat pakettimäärän, jota voidaan verrata kahden vertaislaitteen välillä, mikä yleensä on laskemisen syy. Kumpikaan ei kerro, vastattiinko sisäiseen pyyntöön.

Älä käsittele UDP 4500 -määrää ESP-pakettien määränä. IKE käyttää kyseistä porttia myös NAT-T-elossapitoviesteihin ja kapseloituun vaihtoon, joten luku sisältää liikennettä, joka ei ole dataa, jota halusit mitata. Alkuperäinen IKE-vaihto UDP 500:ssa tarvitsee oman suodattimensa, jos se on kysymys. Luku, joka sekoittaa ohjausliikennettä dataan, tekee myös kaikki kaistanleveysarviot virheellisiksi tuntemattomalla marginaalilla. Erilliset laskennat vastaavat erillisiin kysymyksiin.

Kirjoita suodatin sen kysymyksen viereen, johon se vastaa. „Paljonko ESP:tä lähti laatikosta“ ja „lähtikö verkkopyyntö laatikosta“ ovat eri mittauksia eri suodattimilla, eikä yksi kaappaus ratkaise molempia. Ilman tuota merkintää kaksi ihmistä vertailee lukuja, jotka eivät koskaan laskeneet samaa asiaa.

Tarkkaile ennen muunnosta, älä sen jälkeen

Jos sinun on nähtävä lähtevä selkokieli, siirrä tarkkailupiste aikaisemmaksi, ennen IPsecin lähtökäsittelyä. NFLOG antaa sinulle Netfilter-koukun, jossa sääntö voi kopioida valittuja paketteja käyttäjätilan socketiin, jota tcpdump osaa lukea. strongSwanin liikenteen kaappausopas dokumentoi tämän lähestymistavan juuri tästä syystä.

Käytäntövastaavuus rajaa säännön liikenteeseen, joka on juuri astumassa tunneliin. -m policy --pol ipsec --dir out on se, mikä tekee säännöstä täsmällisen sen sijaan, että lokiin kirjattaisiin jokainen laatikon lähettämä paketti. Lue sitten lokiryhmä rajatulla kaappauksella: pieni tilannekuvien määrä ja kokoraja estävät diagnostiikkaa muuttumasta liikennearkistoksi. Rajattu kaappaus on myös helpompi antaa arvioijalle ilman, että mukaan raahataan asiatonta hyötykuormaa. Päätä määrä ennen aloittamista, ei sen jälkeen kun näet, paljonko saapui.

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'

Valitse koukku virtausta vastaavaksi. OUTPUT kattaa liikenteen, jonka yhdyskäytävä itse tuottaa; LAN-asiakkaan läpikulku menee sen sijaan FORWARD-ketjun läpi, eikä OUTPUT-sääntö näe sitä koskaan. Yllä oleva osoite ja portti ovat paikkamerkkejä hyväksytylle testikohteelle.

Mitä havainto todistaa

NFLOG on lokituskohde, ei hyväksymispäätös. Siellä näkyvä paketti osoittaa, että se saavutti koukun ja täytti säännön. Se ei osoita, että myöhempi suodatin päästi sen läpi, että laite lähetti sen tai että vastapuoli vastaanotti jotain.

Tyhjä loki on yhtä tulkinnanvarainen. Tarkista säännön pakettilaskuri, vahvista suunta, vahvista että virtaus todella vastasi IPsec-käytäntöä ja vahvista kohde. Vain molemmilla vertaislaitteilla täsmäävä laskuri muuttaa havainnon johtopäätökseksi. Vertaa sitten turva-assosiaation laskureita molemmilla vertaislaitteilla saman kontrolloidun yrityksen osalta, koska SA-laskurit ovat auktoritatiivinen kirjaus siitä, mikä suojattiin ja lähetettiin.

Vielä yksi ansa: „selkokieli“ tarkoittaa tässä yhteydessä IPsec-salauskerroksen ulkopuolella. Sisäisellä HTTPS-istunnolla on edelleen oma TLS. Puretun paketin kaappaaminen ei pura sovelluksen TLS:ää, ja luettavan HTTP:n näkeminen siinä tarkoittaa, ettei sovellus koskaan käyttänyt HTTPS:ää.

Siivoa ja vertaa molempia päitä

Poista täsmälleen se sääntö, jonka lisäsit, sen omistajan mukaan, heti kun havainnointi on valmis. Paikalleen jätetty lokitussääntö maksaa prosessoritehoa jokaisella täsmäävällä paketilla ja luo hiljaa tietojen säilytysongelman. Poista toistamalla sääntö -D:llä sen sijaan, että tyhjentäisit ketjun, joka ei ole sinun.

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

Jos käyttöönotto käyttää käyttäjätilan IPseciä, XFRM-rajapintaa tai laitteistopurkua, tarkkailupisteet siirtyvät eikä tämä resepti välttämättä päde lainkaan. Libipsecin kanssa sisäisen liikenteen tarkkailuun dokumentoitu paikka on TUN-laite. Tunnista ensin polku, valitse sitten piste, joka vastaa kysymykseen, ja odota kahden suunnan näyttävän erilaisilta vain, kun katsot muunnoksen väärää puolta.