IPsec með mörgum undirnetum missir afturumferð? Teljið reqid-in

Umferð fer frá öðrum staðnum og kemur aldrei til baka, báðar gáttirnar tilkynna lokna samninga, og eina vísbendingin er hrúga af útfarandi pökkum án svara. Á Linux-endapunkti er venjulega orsökin ekki styrkur dulritunar, MTU eða beiningartafla. Það er kornastærð stefnufærslnanna og númerið sem tengir hverja stefnu við öryggistengingu. Ferlið hér að neðan les þessa tvo gagnagrunna áður en nokkuð annað er snert.

Skiptu einkenninu í sundur áður en þú breytir nokkru

Einslega bilun með lokinni IKE-samninga þrengir vandamálið að gagnaleiðinni. Annaðhvort passaði útfarandi stefnan og svarinu var hent, eða svarið kom aldrei því hin hliðin hafði ekkert til að senda það gegnum. Frá forriti líta bæði eins út, og xfrm-gagnagrunnarnir greina þau.

Ekki byrja á MTU. Röng MTU gefur stíflur og sundrunareinkenni, ekki hreina stefnuskiptingu með hækkandi útfarandi teljurum.

Lestu stefnugagnagrunninn og stöðugagnagrunninn

Dulritun á Linux ræðst af stefnufærslum, svo viðeigandi stefna, ekki leið, er það sem setur pakka í göngin. Keyrðu ip xfrm policy til að sjá val, stefnu, forgang og sniðmát hverrar færslu, og ip xfrm state til að sjá komnar tengingar með reqid-unum þeirra. Stefnan og tengingin eru tengdar með því reqid.

Skoðaðu allar þrjár stefnurnar. Útfarandi og innfarandi ná yfir umferð til og frá þessum vél; framstefnan skiptir máli þegar vélin beinir fyrir aðra. Vantar færslu eða hún er frábrugðin í einni stefnu, útskýrir það einslega niðurstöðu án nokkurrar dulritunarbilunar.

Klassíska ósamhverfan: eitt reqid fyrir mörg undirnet

Algeng bilun kemur frá jafningja sem setur stefnur fyrir öll samninguð undirnet undir einu reqid, sem gerist með generate_policy require hjá racoon. Umferðin fer þá út um þá tengingu sem var stofnuð síðast, á meðan hin hliðin heldur sérstakri tengingu fyrir hvert undirnet. Svör berast á tengingu þar sem reqidið tilgreinir ekki stefnuna sem ætti að samþykkja þau, og kjarninn hendir þeim eftir afkóðun.

Lausnin er stillingarbreyting, ekki eldveggjarregla: generate_policy unique; gefur hverri stefnu eigið reqid, svo tengingar jafningsins fyrir hverja stefnu hafa samsvarandi maka. Notaðu það, semdu aftur og teljið mismunandi reqid fyrir undirnetin sem þú býst við áður en þú lýsir árangri.

Ef tvö undirnet deila enn reqid á meðan hin hliðin býst við tveimur, hefur þú fundið ósamhverfuna. Skráðu vörpunina, því hún er sönnunin fyrir því hvort næsta breyting lagaði hana eða varðveitti hana.

Valin koma frá samningunum, ekki stillingunni þinni

Vernduð sviðin eru það sem báðir endar sömdu um, ekki það sem önnur hliðin bað um. Biðlarinn sem býður vélpar á móti breiðu fjarsviði fær þrengda útgáfu gáttarinnar, og biðlarinn getur ekki víkkað hana. Lestu uppsett valin frekar en þau í staðbundnu skránni þinni.

Þegar markmiðið er hið gagnstæða, að halda einum áfangastað utan gönganna, bættu við framhjáhlaupstefnu með lægra forgangsnúmeri svo hún vinni á móti sjálfkrafa uppsettu færslunni. Stefna án sniðmáts leyfir ódulritaðan texta, sem gerir hana að viljandi undantekningu fyrir breytingaskrá frekar en villuleitarskrefi.

Staðfestu í þessari röð, og vitið hvernig á að bakka út

Skráðu stefnur fyrir hvert undirnet í báðum stefnum, þar á meðal fram ef vélin beinir. Teljið mismunandi reqid og staðfestið eitt á hverja stefnu á hliðinni sem býst við því. Berið uppsett val saman við samninguðu valin. Lestu teljara tengingarinnar aftur eftir endurnýjun lykils, því tengingin sem þú skoðaðir getur þegar verið farin. Athugaðu leiðir síðast, því leið sem vantar að fjaraundirnetinu gefur svipað einslega einkenni með hreinum stefnuteljurum.

Áður en þú breytir jafningjanum skaltu vista núverandi úttak beggja xfrm-skipananna. Ef nýja stillingin endurheimtir ekki afturstefnuna er að endurheimta það úttak hraðari afturköllun en að endurbyggja göngin úr minni, og það heldur samanburðinum heiðarlegum.