Waarom 'n OpenVPN-roete verloor teen 'n strongSwan XFRM-beleid

Pakke kan 'n OpenVPN-roete volg en steeds deur 'n IPsec-beleid gevang word, en daardie kombinasie lyk uit elke hoek soos 'n roetefout behalwe uit die regte een. Linux los 'n roete op en raadpleeg dan 'n aparte sekuriteitsbeleiddatabasis, so 'n meer spesifieke bestemmingsroete verplaas nie 'n ooreenstemmende XFRM-beleid nie. Die sigbare simptoom is verkeer wat die gasheer verlaat en nooit aankom nie, terwyl albei tonnels hulself gesond rapporteer. Drie opsies los dit op, en watter een jy kies hang daarvan af watter van die twee paaie bedoel is om daardie voorvoegsel te dra.

Twee besluite, nie een nie

Roeteseleksie antwoord op 'n eng vraag: watter volgende sprong en bronadres moet hierdie pakkie dra. Die sekuriteitsbeleiddatabasis antwoord 'n ander een: vereis hierdie pakkie IPsec-beskerming, en onder watter keurders. Albei loop vir dieselfde pakkie, en die eerste bevredig sê niks oor die tweede nie. Dit is waarom die verandering van 'n maatstaf of die byvoeging van 'n statiese roete die simptoom onaangeraak kan laat.

'n Breë IPsec-keurder is die gewone oorsaak. 'n Beleid wat 172.16.0.0/12 beskerm, dek ook 172.20.8.0/24, wat 'n administrateur dalk eerder deur die OpenVPN-tonnel wil bereik. Die bedoeling bestaan net in die roetetabel, en die beleiddatabasis het nooit daarvan geleer nie.

Behandel dit as 'n konflik tussen twee gekonfigureerde beskermingspaaie eerder as 'n stryd tussen twee maatstawwe. Die regstelling hoort in watter komponent ook al met die verkeerde omvang gekonfigureer is.

Lees die roete wat die kern werklik kies

Begin met die opsoek wat die kern doen, insluitend die bronadres en enige beleidsreël wat dit na 'n ander tabel kan aflei. 'n Roete in die hooftabel word dalk nooit geraadpleeg nie as 'n vroeër reël 'n ander tabel kies, en die passing van die langste voorvoegsel geld net binne die tabel wat 'n reël kies.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Die laaste opdrag is die een wat saak maak, want dit druk die gekose roete saam met die bronadres wat die kern sou gebruik. Vergelyk daardie uitset met die keurder wat die IPsec-beleid pas. Wanneer die roete na die OpenVPN-koppelvlak wys en die beleid pas steeds dieselfde paar, het jy die konflik herproduseer sonder om te raai.

Hou stortings vry van onverwante adresse voordat dit 'n kaartjie bereik. 'n Roetetabel van 'n produksiegasheer dra interne topologie, en net die reëls wat die vraag antwoord, is werd om te plak.

Lees die beleid wat ook geld

Die beleidslys wys rigting, keurders en die sjabloon wat besluit wat met 'n ooreenstemmende pakkie gebeur. Lees eers die uitgaande rigting, dan die inkomende kant vir die terugkeerverkeer, want 'n eenrigting-uitsondering lewer 'n verbinding wat begin en nooit voltooi nie.

ip -s xfrm policy
swanctl --list-sas

Vergelyk die keurders in die lys met die voorvoegsels wat die verbinding onderhandel het. Om strongSwan se roete-installasie te deaktiveer verwyder nie daardie beleide nie, en die verandering van 'n maatstaf verander nie watter bron- en bestemmingspaar 'n beleid beskerm nie. Daardie twee nie-regstellings is werd om vroeg uit te skakel, want dit is die eerste wat mense probeer.

As die lys geen beleid vir die voorvoegsel bevat wat jy verwag het nie, is die probleem elders en vertel die roetetabel waarskynlik die waarheid. As dit 'n breër beleid bevat wat die voorvoegsel dek, het jy die vangs gevind.

Drie opsies wanneer albei paaie geldig is

Om die IPsec-keurder te vernou is die skoonste opsie wanneer die breë voorvoegsel 'n gerief eerder as 'n vereiste was. Om die remote-verkeerskeurder te verklein tot die subnetwerke wat werklik agter IPsec hoort, verwyder die konflik vir elke gasheer tegelyk, en dit kos 'n herleuteling eerder as 'n nuwe komponent.

'n Deurlaat-uitsondering is die chirurgiese opsie wanneer die breë keurder moet bly. strongSwan ondersteun 'n aparte verbinding waarvan die kind pass-modus gebruik, wat die kern sê dat die ooreenstemmende verkeer nie deur IPsec verwerk moet word nie. Die loopback-remote-adres hou daardie verbinding daarvan weg om vir inkomende eweknieë gekies te word, en die keurders moet die werklike gemagtigde paar beskryf eerder as alles.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Die strongSwan-konfigurasievoorbeelde dokumenteer hierdie beleidstipe en die loopback-eweknie-konvensie. Die derde opsie is 'n roetegebaseerde ontwerp met XFRM-koppelvlakke, wat beleid koppel aan verkeer wat deur 'n genoemde koppelvlak gerouteer word eerder as aan 'n globale keurder. Dit is 'n migrasie eerder as 'n aanpassing, en die verkeer moet steeds die onderhandelde keurders bevredig.

Bewys die uitsondering sonder om die res te verswak

Nadat die verandering gelaai is, toets die uitsondering en 'n gewone bestemming wat beskerm moet bly. Kontroleer albei rigtings, laat dan die OpenVPN-tonnel val en bevestig wat met die uitgesonderde verkeer gebeur. 'n Uitsondering wat daardie voorvoegsel stilweg in die ope lug stuur wanneer die tonnel af is, is 'n beleidsbesluit wat jy doelbewus moet neem, nie tydens 'n voorval moet ontdek nie.

Teken aan watter voorvoegsel watter pad gebruik en waarom. Die volgende ingenieur wat 'n breë keurder sien, sal andersins dieselfde ondersoek heropen, en die antwoord sal in 'n commit-boodskap sit wat niemand lees nie.