Waarom ’n IPsec-beveiligingsbeleid nie ’n roetenaaminskrywing is nie

Ping 10.20.0.5 deur die tonnel en niks kom terug nie, terwyl die roeteblad volhou dat daardie subnet bereikbaar is. Roetering en IPsec beantwoord verskillende vrae, en net een van hulle gaan oor bereikbaarheid. Die voorwaartse soektog kies ’n pad, dan besluit die beveiligingsbeleid-databasis of daardie pad beskerm, met rus gelaat of geweier moet word. Wanneer die twee verskil, sterf die pakkie stil, so lees hulle in daardie volgorde.

Begin by die soektog, nie by die tabel nie

Vra die kern wat hy werklik sou doen: ip route get 10.20.0.5 druk die gekose roete, die uitgaande koppelvlak en die bronadres wat hy sou gebruik. ’n Voorvoegsel, ’n beleidsreël, ’n merkie of ’n voorkeurbron kan almal daardie antwoord verander, en daarom wen die lewendige soektog bo die tabel wat jy met die oog lees.

Toets ’n bestemming binne die beskermde reeks, nie die poortadres nie. Om die oorkantste poort te bereik bewys net dat een of ander roete bestaan; dit sê niks oor die subnet wat jy werklik nodig het nie. Bevestig dan dat die koppelvlak wat die soektog gekies het, die een is wat jy verwag die tonnel sal gebruik.

Pas die keurders aan beide kante

Die beleidsdatabasis hou sy eie inskrywings, en elkeen noem ’n rigting, ’n bron, ’n bestemming en ’n protokol, en sê dan wat met passende pakkies moet gebeur. Gebruik ip xfrm policy om hulle te lys; die vlae wys of die aksie beskerm, omseil of blokkeer is. ’n Beleid waarvan die keurders wyer of nouer as jou toetsvloei is sal dit nie pas nie, en die pakkie verlaat onbeskermd. Dit is die fout wat jy jag, nie ’n ontbrekende roete nie.

Vergelyk die werklike waardes: bron, bestemming, protokol en poorte. As die soektog een adrespaar opgelos het terwyl die beleidsinskrywing ’n ander een dek, beskryf die twee aansigte verskillende verkeer. Herhaal albei met dieselfde tuple voordat jy ’n gevolgtrekking maak, anders wysig jy ’n beleid wat nooit in die pad was nie.

’n Beleidstreffer is nie geïnstalleerde toestand nie

’n Passende beleid sê net die pakkie moet beskerm word; die kern het steeds ’n beveiligingsassosiasie nodig om die beskerming te doen. Lys hulle met ip xfrm state, of met swanctl --list-sas wanneer strongSwan die onderhandeling doen, en lees die keurders en tellers op elke inskrywing.

Wanneer ’n beleid pas en geen assosiasie dek dieselfde keurders nie, word die pakkie laat val eerder as in duidelike teks gestuur. Dit is die val om na te soek wanneer die tonnel op is maar ’n enkele subnet faal. Tellers vertel die res: ’n assosiasie wat nooit toeneem nie was nooit gekies nie, terwyl een wat toeneem en steeds in ’n val eindig na die ander kant wys. Om keurders reg te maak en om te herkey is verskillende herstelwerk, so besluit watter een jy nodig het voordat jy aan die konfigurasie raak.

Wat ’n roetegebaseerde tonnel steeds vereis

’n XFRM-koppelvlak laat die tonnel soos ’n toestel lyk waarin jy kan roeteer, wat werklik nuttig is. Dit verwyder nie die beleid en toestand wat besluit wat gebeur sodra die pakkie daar aankom nie. Die roete dra ’n volgende sprong by en niks meer nie.

As die toestel bestaan en die roete daarin wys terwyl geen assosiasie die innerlike keurders pas nie, word die pakkie weggegooi, en geen hoeveelheid roetewysiging lewer sleutels of keurders nie. Kontroleer die koppelvlak met dieselfde bron en bestemming as wat jy geroteer het, en vergelyk dit dan met die toestandlys.

Bepaal eienaarskap voordat jy iets wysig

’n Gasheer-firewall voeg ’n derde besluit by waarvan nie een van die twee databasisse weet nie. ’n Korrekte roete plus ’n passende beleid plus ’n geïnstalleerde assosiasie kan steeds by ’n laat-val pakkie eindig, en die toepassing rapporteer net die tydsverloop. Bevestig die firewall laat die beskermde verkeer deur voordat jy IPsec blameer. Om op die tonneltoestel en op die fisiese koppelvlak vas te vang wys aan watter kant van die versleuteling die pakkie verdwyn het.

Konfigurasie-eienaarskap bepaal of jou regstelling ’n herbegin oorleef. Een komponent mag toestand installeer terwyl ’n ander een roetes bestuur, en ’n handwysiging aan die tweede word oorgeskryf die volgende keer dat die tonnel opkom. Verander die eienaarskonfigurasie en lees dan albei aansigte weer; RFC 4301 hou die twee databasisse apart wanneer jy die splitsing aan iemand anders moet verduidelik.