Lähtevä ESP ilman vastausta ei tarkoita, että VPN on kuollut
ESP suojaa yhtä suuntaa yhdistystä kohden eikä kuittaa mitään. Kohdista sisäinen keskustelu ja saapuva SA ennen kuin kutsut palvelinta reagoimattomaksi.
Kaappasit liikennettä IPsec-isännässä, näit ESP-pakettien lähtevän, et nähnyt mitään palaavan ja päättelit, että vastapuoli on rikki. Kaappaus ei tue tätä päätelmää. ESP suojaa keskustelun yhtä suuntaa eikä kuittaa mitään IP-kerroksessa, joten puuttuva paluu-ESP voi yhtä hyvin tarkoittaa, ettei sovelluksella ollut mitään sanottavaa, kuin että tunneli on kuollut. Lue sisäinen vaihto ja vastaanottavan puolen tila ennen kuin syytät kumpaakaan päätä.
Myytti: jokainen suojattu paketti ansaitsee vastauksen
ESP ei ole pyyntö-vastaus-protokolla. Se salaa ja todentaa sen, minkä käytäntö valitsee, ja vastaanottaja validoi, purkaa salauksen ja toimittaa tämän sisäisen paketin luomatta omaa pakettia. UDP-kysely, jonka kohde jättää huomiotta, tai ICMP-kaiku, jonka saapuva käytäntö hylkää, tuottavat hiljaisuuden molempiin suuntiin oikeana tuloksena. Sen hiljaisuuden käsitteleminen kuljetusvikana lähettää sinut etsimään verkkovikaa, jota ei koskaan ollut.
Mitä yksisuuntainen kaappaus itse asiassa todistaa, on että lähettäjän pino salasi jotain siinä havaintopisteessä. Ei mitään saapumisesta eikä mitään vastaamisaikeesta. Hyödyllinen kysymys ei ole "miksi vastausta ei ole", vaan "mitä sisäisen keskustelun olisi pitänyt tuottaa".
Kaksi SA:ta, kaksi SPI:tä, yksi keskustelu
IPsec-turvayhdistykset ovat yksisuuntaisia, joten tavallinen suojattu vaihto sisältää saapuvan ja lähtevän yhdistyksen erillisillä tunnisteilla ja riippumattomalla tilalla. Paluuliikenteen etsiminen lähtevän paketin SPI:llä on siksi kategoriavirhe, koska mikä tahansa vastaus kulkee vertaispartnerin oman lähtevän SA:n alla omalla SPI:llään. Yhdistä pari sen sijaan liikenteen valitsimien ja vertaispartnerin osoitteiden perusteella.
Avainten uusiminen monimutkaistaa kuvaa muutamaksi sekunniksi kerrallaan, koska vanha ja korvaava tila voivat mennä päällekkäin. Jos oire alkoi avainten uusimisen tienoilla, kerää yhdistysten tunnisteet ja aikaleimat yhteen eikä vain yhteyden nimeä.
Mitä vastaanottajan on tehtävä ennen kuin mikään vastaa
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Jokainen rivi epäonnistuu itsenäisesti ja jokaisella epäonnistumisella on eri omistaja, minkä vuoksi yksi kaappaus ei pysty erottamaan niitä. Saapuva laskuri on ainoa suora todiste saapumisesta, koska paketti, joka epäonnistuu todentamisessa tai toistotarkistuksessa, hylätään ilman mitään vastausta. Vertaispartneri, jonka saapuva laskuri ei ole liikkunut, ei siis lähetä sinulle mitään tietoa käytännöstään.
Toimitus on erillinen vaihe salauksen purkamisesta. Tila voi olla kelvollinen ja paketti silti hylätä myöhemmin saapuvan käytännön tai reitin toimesta, joka ei sisällä sisäistä kohdetta, joten tarkista, näkikö kohdeisäntä selkokieltä, sen sijaan että olettaisit puhtaan laskurin tarkoittavan, että paketti meni sinne minne halusit.
Natiivi ESP ei ole UDP
Natiivi ESP on IP-protokolla 50, joka ei ole TCP eikä UDP eikä siinä ole yhtään porttia. Siksi palomuurisääntö, joka sallii IKE:n UDP 500:ssa, ei kerro tietoreitistä mitään, ja porttien ympärille kirjoitettu suodatin voi antaa tunnelin neuvotella ja sitten hylätä kaiken, mitä sen sisällä kuljetetaan. Testaa tietoreitti erikseen siinä tilassa, jonka todella havaitsit.
NAT:n takana muoto muuttuu: suojattu hyötykuorma kulkee UDP:n sisällä, tavallisesti portissa 4500, kuten RFC 3948 määrittelee. Kirjaa aktiivinen tila ennen minkään säännön kirjoittamista, koska reitillä oleva laite voi kohdella natiivia ESP:tä ja UDP-kapseloitua ESP:tä täysin eri tavoin, ja jotkin välilaatikot sallivat toisen ja hylkäävät toisen.
Lue laskureita, jotka kuuluvat tähän tapaukseen
strongSwan-isännässä swanctl --list-sas raportoi paketti- ja tavulaskurit yhdistystä kohden molempiin suuntiin, mikä riittää erottamaan "ei koskaan saapunut" tilanteesta "saapui eikä vastattu". Linuxissa /proc/net/xfrm_stat laskee koontuneita vikoja, kuten puuttuva tila, puuttuva käytäntö ja protokollavirheet. Nämä summat kertyvät käynnistyksestä ja kuuluvat yhteen verkon nimiavaruuteen, joten suuri luku ei ole kohdistus.
Ota kaksi lukemaa tapauksen ikkunan ympäriltä oikeassa nimiavaruudessa ja vertaa eroja, muuten kiinnität viime viikon virheet tämän iltapäivän tikettiin. Kirjoita nimiavaruus ja molemmat aikaleimat tikettiin, jotta seuraava lukija voi toistaa vertailun sen sijaan että luottaisi summaan.
Nimeä vaihe, älä epäiltyä
Hyödyllinen johtopäätös kertoo, mihin paketti pysähtyi: ei koskaan vastaanotettu, vastaanotettu ja hylätty, toimitettu mutta vastaamatta, tai vastattu ja kadonnut paluumatkalla. Jokainen näistä osoittaa eri omistajaan ja eri seuraavaan komentoon. "Ei vastausta VPN-palvelimelta" puristaa neljä erillistä vikaa yhteen lauseeseen, jota kaappaus ei koskaan oikeuttanut.
Pidä kaappaukset kapeina ja pidä raaka ytimen tila poissa tiketeistä, koska se voi sisältää avainmateriaalia, jolla ei ole mitään asiaa isännän ulkopuolelle. Laskurien erot ja aikaleimat ovat ne osat, jotka kannattaa antaa seuraavalle henkilölle.