Af hverju IPsec-öryggisstefna er ekki færsla í leiðartöflu

Pingaðu 10.20.0.5 í gegnum göngin og ekkert kemur til baka, á meðan leiðartaflan fullyrðir að það undirnet sé aðgengilegt. Leiðastýring og IPsec svara mismunandi spurningum, og aðeins önnur þeirra snýst um aðgengi. Leiðarleitin áfram velur slóð, síðan ákveður gagnagrunnur öryggisstefnunnar hvort vernda þurfi þá slóð, láta hana ósnorta eða hafna henni. Þegar þau tvö eru ósammála deyr pakkinn hljóðlega, svo lestu þau í þessari röð.

Byrjaðu á leitinni, ekki töflunni

Spurðu kjarnann hvað hann myndi raunverulega gera: ip route get 10.20.0.5 prentar valda leið, útgangsviðmótið og upprunafangið sem hann myndi nota. Forskeyti, stefnuregla, merki eða valið upprunafang geta allt breytt þessu svari, sem er ástæðan fyrir því að lifandi leitin vinnur á lestri töflunnar með auganu.

Prófaðu áfangastað innan varða sviðsins, ekki gáttarfangið. Að ná gáttinni hinum megin sannar aðeins að einhver leið sé til; það segir ekkert um undirnetið sem þú þarft í raun. Staðfestu síðan að viðmótið sem leitin valdi sé það sem þú býst við að göngin noti.

Láttu valþættina passa á báðum hliðum

Stefnugagnagrunnurinn hefur sínar eigin færslur, og hver þeirra nefnir stefnu, uppruna, áfangastað og samskiptareglu, og segir síðan hvað eigi að gera við pakka sem passa. Notaðu ip xfrm policy til að lista þær; flöggin sýna hvort aðgerðin er vernd, framhjáhlaup eða blokkun. Stefna þar sem valþættirnir eru víðari eða þrengri en prófunarflæðið þitt mun ekki passa við það, og pakkinn fer óvarinn út. Það er bilunin sem þú ert að leita að, ekki leið sem vantar.

Berðu saman raunverulegu gildin: uppruna, áfangastað, samskiptareglu og port. Ef leitin leysti eitt fangapar á meðan stefnufærslan nær yfir annað, lýsa báðar sýnirnar mismunandi umferð. Keyrðu báðar aftur með sama tuple áður en þú dregur ályktun, annars breytir þú stefnu sem var aldrei á slóðinni.

Stefnusamsvörun er ekki uppsett staða

Passandi stefna segir aðeins að vernda þurfi pakkann; kjarninn þarf samt öryggissamtengingu til að framkvæma verndina. Listaðu þær með ip xfrm state, eða með swanctl --list-sas þegar strongSwan annast samningaviðræðurnar, og lestu valþættina og teljarana á hverri færslu.

Þegar stefna passar og engin samtenging nær yfir sömu valþætti, er pakkanum hent í stað þess að senda hann í klártæki. Það er hentingin sem á að leita að þegar göngin eru uppi en eitt undirnet bregst. Teljararnir segja afganginn: samtenging sem stækkar aldrei var aldrei valin, en sú sem stækkar og endar samt í hentingu bendir á fjarlægu hliðina. Að laga valþætti og að endurnýja lykla eru mismunandi viðgerðir, svo ákveddu hvor þú þarft áður en þú snertir stillingarnar.

Hvað leiðartengd göng krefjast enn

XFRM-viðmót lætur göngin líta út eins og tæki sem þú getur beint leiðum inn í, sem er sannarlega gagnlegt. Það fjarlægir ekki stefnuna og stöðuna sem ákveða hvað gerist þegar pakkinn kemur þangað. Leiðin leggur til næsta stökk og ekkert meira.

Ef tækið er til og leiðin bendir inn í það á meðan engin samtenging passar við innri valþættina, er pakkanum hent, og engin leiðabreyting framleiðir lykla eða valþætti. Athugaðu viðmótið með sama uppruna og áfangastað og þú beindir leiðum að, og berðu það svo saman við stöðulistann.

Skilgreindu eignarhald áður en þú breytir einhverju

Eldveggur hýsilsins bætir við þriðju ákvörðun sem hvorugur gagnagrunnurinn þekkir. Rétt leið ásamt passandi stefnu ásamt uppsettri samtengingu geta samt endað í hentum pakka, og forritið tilkynnir aðeins tímamörkin. Staðfestu að eldveggurinn leyfi varða umferðina áður en þú kennir IPsec um. Upptaka á gangatækinu og á líkamlega viðmótinu sýnir hvoru megin dulkóðunarinnar pakkinn hvarf.

Eignarhald stillinganna ákveður hvort viðgerðin þín lifir endurræsingu. Einn þáttur getur sett upp stöðu á meðan annar stýrir leiðum, og handbreyting á þeim seinni er skrifuð yfir næst þegar göngin fara upp. Breyttu eignarstillingunni og lestu svo báðar sýnirnar aftur; RFC 4301 heldur gagnagrunnunum tveimur aðskildum þegar þú þarft að útskýra skiptinguna fyrir einhverjum öðrum.