IPsec z več podomrežji izgublja povratni promet? Preštejte reqid

Promet zapusti eno lokacijo in se nikoli ne vrne, oba prehoda poročata o zaključeni pogajanji, edini namig pa je kup odhodnih paketov brez odgovorov. Na Linux končni točki običajni vzrok ni moč šifriranja, MTU ali usmerjevalna tabela. To je drobnozrnatost vnosov politike in številka, ki povezuje vsako politiko z varnostno povezavo. Spodnji postopek prebere ti dve bazi, preden se dotakne česar koli drugega.

Ločite simptom, preden karkoli spremenite

Enosmerna napaka z zaključeno pogajanjo IKE zoži težavo na podatkovno pot. Ali se je odhodna politika ujemala in je bil odgovor zavržen, ali pa odgovor ni nikoli prispel, ker druga stran ni imela s čim poslati. Z vidika aplikacije sta oba primera enaka, baze xfrm pa ju ločijo.

Ne začnite z MTU. Napačen MTU povzroči zastoje in simptome razdrobljenosti, ne čiste ločitve smeri z naraščajočimi odhodnimi števci.

Preberite bazo politik in bazo stanj

V Linuxu o šifriranju odločajo vnosi politike, zato ustrezna politika, ne pot, je tisto, kar spravi paket v tunel. Zaženite ip xfrm policy, da vidite selektorje, smer, prioriteto in predlogo vsakega vnosa, in ip xfrm state, da vidite vzpostavljene povezave z njihovimi reqid. Politika in povezava sta povezani s tem reqid.

Poglejte vse tri smeri. Odhodna in vhodna pokrivata promet do in od tega gostitelja; smer naprej je pomembna, ko gostitelj usmerja za druge. Manjkajoč ali neskladen vnos v eni smeri pojasni enosmerni rezultat brez kakršne koli kriptografske napake.

Klasična asimetrija: en reqid za več podomrežij

Pogosta napaka prihaja od partnerja, ki namesti politike za vsa dogovorjena podomrežja pod enim samim reqid, kar se zgodi z generate_policy require pri racoonu. Promet nato odhaja skozi povezavo, ki je bila vzpostavljena zadnja, medtem ko druga stran ohranja ločeno povezavo za vsako podomrežje. Odgovori prispejo na povezavo, katere reqid ne označuje politike, ki bi jih morala sprejeti, in jedro jih po dešifriranju zavrže.

Popravek je sprememba konfiguracije, ne požarnozidno pravilo: generate_policy unique; da vsaki politiki svoj reqid, tako da imajo povezave partnerja na politiko ustrezne partnerje. Uporabite ga, znova se pogajajte in preštejte različne reqide za pričakovana podomrežja, preden razglasite uspeh.

Če si dve podomrežji še vedno delita reqid, medtem ko druga stran pričakuje dva, ste našli asimetrijo. Zapišite preslikavo, ker je dokaz, ali jo je naslednja sprememba popravila ali ohranila.

Selektorji prihajajo iz pogajanja, ne iz vaše konfiguracije

Zaščiteni obsegi so tisto, o čemer sta se dogovorila oba konca, ne tisto, kar je zahtevala ena stran. Odjemalec, ki ponuja par gostiteljev proti širokemu oddaljenemu obsegu, prejme zoženo različico prehoda, in odjemalec je ne more razširiti. Preberite nameščene selektorje namesto tistih v vaši lokalni datoteki.

Ko je cilj nasproten, obdržati en cilj zunaj tunela, dodajte politiko obvoza z nižjo prioritetno številko, da premaga samodejno nameščen vnos. Politika brez predloge dovoljuje navadno besedilo, kar jo naredi namerno izjemo za zapis spremembe namesto koraka razhroščevanja.

Preverite v tem vrstnem redu in vedite, kako se umakniti

Naštejte politike za vsako podomrežje v obeh smereh, vključno s smerjo naprej, če gostitelj usmerja. Preštejte različne reqide in potrdite enega na politiko na strani, ki ga pričakuje. Primerjajte nameščene selektorje z dogovorjenimi. Po obnovitvi ključa znova preberite števce na povezavo, ker povezava, ki ste jo pregledali, morda že ni več. Poti preverite nazadnje, saj manjkajoča pot do oddaljenega podomrežja povzroči podoben enosmerni simptom s čistimi števci politike.

Preden spremenite partnerja, shranite trenutni izhod obeh ukazov xfrm. Če nova nastavitev ne obnovi povratne smeri, je obnovitev tega izhoda hitrejša vrnitev kot ponovna gradnja tunela po spominu, in ohrani pošteno primerjavo.