Razlikovanje fragmentacije IKEv2 od težave z verigo potrdil
Ko se rokovanje ustavi takoj po prvi izmenjavi, ugotovite, ali sporočilo ni nikoli prispelo ali je bilo zavrnjeno, preden se dotaknete potrdil.
Predor je deloval v pisarniškem omrežju in se doma ustavi, dnevnik pa kaže, da se prva izmenjava zaključi, preden se zgodi karkoli drugega. Ta vzorec kaže na izmenjavo preverjanja pristnosti, ne na poverilnice: veriga potrdil naredi to sporočilo veliko večje od prejšnjega, pot, ki ne mara velikih datagramov, pa ga tiho zavrže. Vključena sta dva različna mehanizma fragmentacije, in vedeti, katerega gledate, odloči o popravku.
Dva mehanizma fragmentacije, en simptom
IKEv2 ima svojo razširitev fragmentacije, opredeljeno v RFC 7383, ki zaščitena sporočila IKE razdeli na manjša sporočila IKE. Stranki se o tej zmožnosti pogajata, sporočilo pa znova sestavi izvedba IKE in ne plast IP.
Običajna fragmentacija IP je drug mehanizem z drugačnim načinom odpovedi. Usmerjevalnik med stranema fragmentira velik datagram ali ga zavrže in vrne sporočilo ICMP, ki morda nikoli ne doseže pošiljatelja. Nekatera omrežja fragmente tiho zavržejo, nekateri vmesni elementi pa obdelajo prvi fragment, ne pa preostalih. Z vidika aplikacije so vsi trije primeri videti enaki.
Prehod skozi NAT doda tretjo spremenljivko, ker je ESP takrat ovit v UDP in zunanji paket postane večji, medtem ko je videti kot običajen promet UDP na vratih 4500. Pot, ki dobro prepušča UDP, lahko še vedno odpove pri datagramu, ki ne gre več noter.
Preberite izmenjavo, ki ni uspela
Iščite prehod, ne napake. Dnevnik, ki kaže prvo izmenjavo poslano in odgovorjeno, nato pa nič, vam pove, da se naslednje sporočilo ni nikoli končalo. Začasno dvignite raven dnevnika in primerjajte sporočene velikosti na obeh straneh.
Kar želite ugotoviti, je, ali je odzivnik zahtevo sploh videl. Če je začetnik kaj poslal in odzivnik o tem nima nobenega zapisa, je težava v dostavi. Če je odzivnik zahtevo razčlenil in jo zavrnil, je težava v samem potrdilu, fragmentacija pa odvrača pozornost. To razlikovanje je vredno več kot stran sporočil o poteku časa.
Spremenite pot, ne potrdila
Preizkusite istega odjemalca, isto potrdilo in isto konfiguracijo iz drugega omrežja. Mobilna dostopna točka je običajno najcenejša druga pot in se resnično razlikuje od pisarniške povezave, ne le nominalno.
Če se rokovanje na drugi poti zaključi, je veriga potrdil v redu in spremenljivka je prva pot. Če na obeh odpove enako, prenehajte preizkušati omrežja in poglejte sama sporočila. Ta ena primerjava odstrani približno polovico možnih razlag.
Izmerite izmenjavo, preden karkoli uredite
Pridobite velikost verige in velikost poti. Obe števili omejujeta, kaj lahko rokovanje pošlje, in obe je poceni izmeriti:
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'
Prva dva dajeta število potrdil in velikost datoteke, kar je razumen pokazatelj, kako veliko bo sporočilo preverjanja pristnosti. Preizkus ping poroča, ali datagram te velikosti preživi pot, števci vmesnika pa kažejo, ali so bili fragmenti na vaši strani zavrženi. V sistemu Windows je enakovreden preizkus ping z zastavico do-not-fragment in izrecno velikostjo koristne obremenitve.
Preizkus ponavljajte navzdol, dokler ne uspe. Največja velikost, ki gre skozi, je delovni proračun za to pot in je uporabnejša od katerekoli objavljene privzete vrednosti.
Popravite plast, ki je resnično pokvarjena
Če pot zavrže velike datagrame, omogočite fragmentacijo IKE na obeh straneh in potrdite, da je bila razširitev dogovorjena, ne le ponujena. Če pot slabo ravna s fragmenti na ravni IP, popravek sodi tja ali v MTU zunanjega vmesnika, ne v shrambo potrdil.
Če je veriga nepotrebno dolga, jo skrajšajte na vmesna potrdila, ki jih stran resnično potrebuje. Odstranitev korena, ki mu odjemalec že zaupa, je razumno vzdrževanje; odstranitev vmesnega ni, in izklop preverjanja za zmanjšanje sporočila zamenja težavo z dostavo za varnostno težavo.
Zapišite, kateri mehanizem ste spremenili in kako je rokovanje izgledalo po tem. Naslednji pojav je običajno v drugem omrežju z istim simptomom, in prav zapisek spremeni dve uri v deset minut.