IPsec met veelvuldige subnetwerke verloor terugkeerverkeer? Tel die reqids

Verkeer verlaat die een terrein en kom nooit terug nie, albei gateways rapporteer 'n voltooide onderhandeling, en die enigste leidraad is 'n hoop uitgaande pakkette sonder antwoorde. Op 'n Linux-eindpunt is die gewone oorsaak nie enkripsiesterkte, die MTU of 'n roeteringstabel nie. Dit is die granulariteit van die beleid-inskrywings en die nommer wat elke beleid aan 'n sekuriteitsassosiasie koppel. Die prosedure hieronder lees daardie twee databasisse voordat enigiets anders aangeraak word.

Skei die simptoom voordat jy iets verander

'n Eenrigtingfout met 'n voltooide IKE-onderhandeling vernou die probleem tot die datapad. Óf die uitgaande beleid het gepas en die antwoord is weggegooi, óf die antwoord het nooit aangekom nie omdat die ander kant niks gehad het om dit deur te stuur nie. Vanuit 'n toepassing lyk albei dieselfde, en die xfrm-databasisse onderskei hulle.

Moenie met die MTU begin nie. 'n Verkeerde MTU lewer stollings- en fragmentasiesimptome, nie 'n skoon rigtingskeiding met stygende uitgaande tellers nie.

Lees die beleidsdatabasis en die state-databasis

Enkripsie op Linux word deur beleid-inskrywings bepaal, dus 'n passende beleid, nie 'n roete nie, is wat 'n pakket in die tonnel plaas. Voer ip xfrm policy uit om die selectors, rigting, prioriteit en sjabloon van elke inskrywing te sien, en ip xfrm state om die gevestigde assosiasies met hul reqids te sien. Die beleid en die assosiasie word deur daardie reqid verbind.

Kyk na al drie rigtings. Uitgaande en inkomende dek verkeer na en van hierdie gasheer; die vorentoe-rigting maak saak wanneer die gasheer vir ander roeteer. 'n Ontbrekende of afwykende inskrywing in een rigting verduidelik 'n eenrigtingresultaat sonder enige kriptografiese fout.

Die klassieke asimmetrie: een reqid vir verskeie subnetwerke

'n Algemene fout kom van 'n eweknie wat beleide vir alle onderhandelde subnetwerke onder een reqid installeer, wat met racoon se generate_policy require gebeur. Verkeer vertrek dan deur die assosiasie wat laas gevestig is, terwyl die ander kant 'n aparte assosiasie per subnetwerk hou. Antwoorde kom aan op 'n assosiasie wie se reqid nie die beleid aandui wat hulle behoort te aanvaar nie, en die kern gooi hulle ná dekripsie weg.

Die oplossing is 'n konfigurasieverandering, nie 'n vuurmuur-reël nie: generate_policy unique; gee elke beleid sy eie reqid, sodat die eweknie se assosiasies per beleid passende vennote het. Pas dit toe, onderhandel weer, en tel die afsonderlike reqids vir die subnetwerke wat jy verwag voordat jy sukses verklaar.

As twee subnetwerke steeds 'n reqid deel terwyl die ander kant twee verwag, het jy die asimmetrie gevind. Teken die koppeling aan, want dit is die bewyse dat die volgende verandering dit reggestel of behou het.

Selectors kom uit die onderhandeling, nie uit jou konfigurasie nie

Die beskermde reekse is wat albei kante ooreengekom het, nie wat een van die kante gevra het nie. 'n Kliënt wat 'n gasheerpaar teen 'n breë afgeleë reeks aanbied, kry die gateway se vernoude weergawe, en die kliënt kan dit nie verbreed nie. Lees die geïnstalleerde selectors eerder as dié in jou plaaslike lêer.

Wanneer die doel die teenoorgestelde is, om een bestemming buite die tonnel te hou, voeg 'n verbygaan-beleid by met 'n laer prioriteitsnommer sodat dit die outomaties geïnstalleerde inskrywing wen. 'n Beleid sonder sjabloon laat gewone teks toe, wat dit 'n doelbewuste uitsondering vir 'n veranderingsrekord maak eerder as 'n ontfoutingsstap.

Kontroleer in hierdie volgorde, en weet hoe om terug te draai

Lys beleide vir elke subnetwerk in albei rigtings, insluitend vorentoe as die gasheer roeteer. Tel afsonderlike reqids en bevestig een per beleid aan die kant wat dit verwag. Vergelyk geïnstalleerde selectors met die onderhandelde. Lees tellers per assosiasie weer ná 'n rekey, want die assosiasie wat jy ondersoek het, kan al weg wees. Kontroleer roetes laaste, want 'n ontbrekende roete na die afgeleë subnetwerk lewer 'n soortgelyke eenrigtingsimptoom met skoon beleidstellers.

Voordat jy die eweknie verander, stoor die huidige uitset van albei xfrm-opdragte. As die nuwe instelling nie die terugrigting herstel nie, is dit om daardie uitset te herstel 'n vinniger terugrol as om die tonnel uit die geheue te herbou, en dit hou die vergelyking eerlik.