IKEv2-fragmentoinnin erottaminen varmentoketjun ongelmasta
Kun kättely pysähtyy heti ensimmäisen vaihdon jälkeen, selvitä, jäikö viesti kokonaan saapumatta vai hylättiinkö se ennen kuin kosket varmenteisiin.
Tunneli toimi toimiston verkossa ja pysähtyy kotona, ja loki näyttää ensimmäisen vaihdon valmistuvan ennen kuin mitään muuta tapahtuu. Tämä kuvio viittaa todennusvaihtoon, ei tunnistetietoihin: varmenneketju tekee viestistä paljon suuremman kuin edellinen, ja polku, joka ei pidä suurista datagrammeista, pudottaa sen hiljaa. Mukana on kaksi erilaista fragmentointimekanismia, ja tieto siitä, kumpaa katsot, ratkaisee korjauksen.
Kaksi fragmentointimekanismia, yksi oire
IKEv2:lla on oma fragmentointilaajennuksensa, joka on määritelty RFC 7383:ssa ja jakaa suojatut IKE-viestit pienempiin IKE-viesteihin. Osapuolet neuvottelevat tästä ominaisuudesta, ja viestin kokoaa uudelleen IKE-toteutus eikä IP-kerros.
Tavallinen IP-fragmentointi on eri mekanismi, jolla on erilainen vikatila. Osapuolten välinen reititin pilkkoo suuren datagrammin tai pudottaa sen ja palauttaa ICMP-viestin, joka ei ehkä koskaan saavuta lähettäjää. Jotkin verkot hylkäävät fragmentit hiljaa, ja jotkin välilaiteet käsittelevät ensimmäisen fragmentin mutta eivät loput. Sovelluksen näkökulmasta kaikki kolme tapausta näyttävät samanlaisilta.
NAT-läpäisy lisää kolmannen muuttujan, koska silloin ESP kääritään UDP:hen ja ulompi paketti kasvaa näyttäen samalla tavalliselta UDP-liikenteeltä portissa 4500. Polku, joka päästää UDP:n hyvin läpi, voi silti epäonnistua datagrammissa, joka ei enää mahdu.
Lue vaihto, joka epäonnistui
Etsi siirtymää, älä virhettä. Loki, joka näyttää alkavan vaihdon lähetettynä ja vastattuna ja sen jälkeen ei mitään, kertoo, ettei seuraava viesti koskaan valmistunut. Nosta lokitasoa tilapäisesti ja vertaa ilmoitettuja kokoja molemmilla osapuolilla.
Haluat selvittää, näkikö vastaaja pyynnön lainkaan. Jos aloittaja lähetti jotain eikä vastaajalla ole siitä mitään merkintää, ongelma on toimituksessa. Jos vastaaja jäsensi pyynnön ja hylkäsi sen, ongelma on itse varmenteessa, ja fragmentointi on harhautus. Tämä ero on arvokkaampi kuin sivu aikakatkaisuviestejä.
Vaihda polku, älä varmenne
Testaa samaa asiakasta, samaa varmennetta ja samaa kokoonpanoa toisesta verkosta. Mobiilitukiasema on yleensä halvin toinen polku, ja se on aidosti erilainen kuin toimiston linkki, ei vain nimellisesti.
Jos kättely valmistuu toisella polulla, varmenneketju on kunnossa ja ensimmäinen polku on muuttuja. Jos se epäonnistuu samalla tavalla molemmilla, lopeta verkkojen testaaminen ja katso itse viestejä. Tämä yksi vertailu poistaa noin puolet mahdollisista selityksistä.
Mittaa vaihto ennen kuin muutat mitään
Hanki ketjun koko ja polun koko. Molemmat luvut rajoittavat sitä, mitä kättely voi lähettää, ja molemmat on halpa mitata:
openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject ls -l chain.pem ping -M do -s 1400 198.51.100.7 ip -s link show eth0 | sed -n '1,6p'
Kaksi ensimmäistä antavat varmenteiden määrän ja tiedoston koon, mikä on kohtuullinen osoitin siitä, kuinka suuri todennusviesti tulee olemaan. Ping-koe kertoo, säilyykö tuon kokoinen datagrammi polulla, ja liittymän laskurit näyttävät, pudotettiinko fragmentteja sinun päässäsi. Windowsissa vastaava koe on ping, jossa on do-not-fragment-lippu ja nimenomainen hyötykuorman koko.
Toista koetta alaspäin, kunnes se onnistuu. Suurin läpimenevä koko on kyseisen polun työbudjetti, ja se on hyödyllisempi kuin mikään julkaistu oletusarvo.
Korjaa kerros, joka on todella rikki
Jos polku pudottaa suuria datagrammeja, ota IKE-fragmentointi käyttöön molemmilla osapuolilla ja varmista, että laajennuksesta neuvoteltiin eikä sitä vain tarjottu. Jos polku käsittelee fragmentteja huonosti IP-tasolla, korjaus kuuluu sinne tai ulomman liittymän MTU:hun, ei varmennevarastoon.
Jos ketju on tarpeettoman pitkä, lyhennä se välivarmenteisiin, jotka osapuoli todella tarvitsee. Juuren poistaminen, johon asiakas jo luottaa, on kohtuullista ylläpitoa; välivarmenteen poistaminen ei ole, ja varmennuksen poistaminen käytöstä viestin pienentämiseksi vaihtaa toimitusongelman turvallisuusongelmaan.
Kirjoita muistiin, mitä mekanismia muutit ja miltä kättely näytti sen jälkeen. Seuraava esiintymä on yleensä toisessa verkossa samalla oireella, ja muistiinpano on se, mikä muuttaa kaksi tuntia kymmeneksi minuutiksi.