Wêrom in OpenVPN-rûte ferliest fan in strongSwan XFRM-belied

Pakketten kinne in OpenVPN-rûte folgje en dochs troch in IPsec-belied fongen wurde, en dy kombinaasje liket fan alle kanten op in routingflater, útsein fan de juste kant. Linux lost in rûte op en rieplachtet dan in aparte feiligensbeliedsdatabank, sadat in mear spesifike bestimmingsrûte in passend XFRM-belied net ferpleatst. It sichtbere symptoom is ferkear dat de host ferlit en nea oankomt, wylst beide tunnels harsels sûn melde. Trije opsjes lossen it op, en hokker jo kieze hinget ôf fan hokker fan de twa paden dat foarheaksel drage moat.

Twa besluten, net ien

Rûtekar antwurdet op in nauwe fraach: hokker folgjende hop en boarneadres moatte dit pakket drage. De feiligensbeliedsdatabank antwurdet op in oare: hat dit pakket IPsec-beskerming nedich, en ûnder hokker selektors. Beide rinne foar itselde pakket, en it earste ferfoljen seit neat oer it twadde. Dêrom kin it feroarjen fan in metryk of it tafoegjen fan in statyske rûte it symptoom ûnoantaast litte.

In breed IPsec-selektor is de gewoane oarsaak. In belied dat 172.16.0.0/12 beskermet, dekt ek 172.20.8.0/24, dêr't in behearder miskien leaver troch de OpenVPN-tunnel komme wol. De bedoeling bestiet allinnich yn de routingtabel, en de beliedsdatabank hat der nea fan wist.

Behannelje dat as in konflikt tusken twa konfigurearre beskermingspaden, net as in wedstriid tusken twa metriken. De reparaasje heart by it komponint dat mei it ferkearde berik konfigurearre is.

Lês de rûte dy't de kernel eins kiest

Begjin mei de syktocht dy't de kernel docht, ynklusyf it boarneadres en elke beliedsregel dy't it nei in oare tabel liede kin. In rûte yn 'e haadtabel wurdt miskien nea rieplachte as in eardere regel in oare tabel kiest, en de langste-foarheaksel-oerienkomst jildt allinnich binnen de tabel dy't in regel kiest.

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

It lêste kommando is it wichtige, want it prints de keazen rûte tegearre mei it boarneadres dat de kernel brûke soe. Fergelykje dy útfier mei de selektor dêr't it IPsec-belied by past. Wannear't de rûte nei it OpenVPN-ynterface wiist en it belied noch altyd by deselde pear past, hawwe jo it konflikt sûnder rieden reprodusearre.

Hâld dumps frij fan net-relatearre adressen foardat se in ticket berikke. In routingtabel fan in produksjehost draacht ynterne topology, en allinnich de rigels dy't de fraach beantwurdzje binne it plakken wurdich.

Lês it belied dat ek jildt

De beliedslist lit rjochting, selektors en it sjabloan sjen dat beslút wat der mei in passend pakket bart. Lês earst de útgeande rjochting, dan de yngeande kant foar it weromferkear, want in ienrjochting-útsûndering makket in ferbining dy't begjint en nea foltôget.

ip -s xfrm policy
swanctl --list-sas

Fergelykje de selektors yn 'e list mei de foarheaksels dy't de ferbining ûnderhannele hat. It útskeakeljen fan strongSwan's rûte-ynstallaasje ferwideret dy beliedsregels net, en it feroarjen fan in metryk feroaret net hokker boarne- en bestimmingspear in belied beskermet. Dy twa falske reparaasjes binne it wurdich om betiid út te sluten, want dat binne de earste dy't minsken besykje.

As de list gjin belied foar it ferwachte foarheaksel befettet, is it probleem earne oars en fertelt de routingtabel wierskynlik de wierheid. As it in breder belied befettet dat it foarheaksel dekt, hawwe jo de opfanging fûn.

Trije opsjes as beide paden legitime binne

It fersmeljen fan 'e IPsec-selektor is de skjinste opsje as it brede foarheaksel in gemak wie ynstee fan in eask. It ferlytsjen fan 'e selektor foar ferfierkear nei de subnetten dy't echt efter IPsec hearre, hellet it konflikt foar elke host tagelyk fuort, en it kostet in nije kaaiferdrach ynstee fan in nij komponint.

In passthrough-útsûndering is de sjirurgyske opsje as de brede selektor bliuwe moat. strongSwan stipet in aparte ferbining wêrfan it child de pass-modus brûkt, wat de kernel fertelt dat it passende ferkear net troch IPsec ferwurke wurde mei. It loopback-fiire adres hâldt dy ferbining tsjin om foar ynkommende peers keazen te wurden, en de selektors moatte it echte autorisearre pear beskriuwe ynstee fan 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
            }
        }
    }
}

De strongSwan-konfiguraasjefoarbylden dokumintearje dit beliedstype en de loopback-peer-konvinsje. De tredde opsje is in routing-basearre ûntwerp mei XFRM-ynterfaces, dat belied bynt oan ferkear dat troch in neamd ynterface rûte is ynstee fan oan in globaal selektor. It is in migraasje en net in oanpassing, en it ferkear moat noch altyd de ûnderhannele selektors foldwaan.

Bewiis de útsûndering sûnder de rest te ferswakjen

Nei it laden fan 'e feroaring, test de útsûndering en in gewoane bestimming dy't beskerme bliuwe moat. Kontrolearje beide rjochtingen, lit dan de OpenVPN-tunnel falle en befêstigje wat der mei it útsûndere ferkear bart. In útsûndering dy't dat foarheaksel stilwei iepen ferstjoert as de tunnel del is, is in beliedsbeslút dat jo mei opset nimme moatte, net ûntdekke by in ynsidint.

Skriuw op hokker foarheaksel hokker paad brûkt en wêrom. Oars sil de folgjende yngenieur dy't in breed selektor sjocht itselde ûndersyk op 'e nij iepenje, en it antwurd sil yn in commit-berjocht stean dat nimmen lêst.