Hoe roete-gebaseerde IPsec met 'n XFRM-koppelvlak werk

Roete-gebaseerde IPsec gee aan die roetertabel 'n besluit wat beleidskeisers vroeër geneem het. Op Linux is die stuk wat dit moontlik maak die XFRM-koppelvlak: 'n virtuele toestel wie se verkeer aan IPsec-toestand gekoppel word deur 'n koppelvlak-identifiseerder eerder as deur 'n keiser. Om een te skep neem 'n enkele opdrag en bewys niks oor of 'n tonnel bestaan nie. Die toestel is 'n haak tussen roetering en sekuriteitsbeleid, en beide kante van daardie haak moet opgestel word voordat enigiets beskerm word.

Wat die toestel is en wat dit nie is nie

'n XFRM-koppelvlak is 'n roetehandvatsel. Pakkette wat daarin gestuur word, word teen XFRM-beleide gemeet wat na dieselfde koppelvlak-identifiseerder verwys, en as 'n beleid en 'n toestand bestaan, word hulle ingekapsel. Sonder dit bestaan die koppelvlak, tellers bly stil, en die verkeer gaan nêrens nuttig heen nie.

Dit is die eerste diagnostiese skeiding. 'n Roete in die toestel in is 'n roeteringsfeit, 'n geïnstalleerde toestand is 'n sekuriteitsfeit, en 'n stygende teller op die toestel is nie een van die twee nie. Wanneer mense sê die tonnel is op omdat die koppelvlak UP wys, beskryf hulle die skakelvlae van 'n virtuele toestel wat geen eie eweknie het nie. Die vlag beteken die toestel is geskep en geaktiveer, niks meer nie.

Nog een grens: die koppelvlak-identifiseerder is nie 'n naam nie. Twee toestelle met soortgelyke name en verskillende identifiseerders deel nie toestand nie, en 'n verbinding wat met die verkeerde identifiseerder opgestel is, installeer toestand wat geen roete ooit sal gebruik nie.

Bou een in die regte volgorde

Begin met die buitenste toestel en 'n nommer wat jy ook in die daemon-opset sal plaas. Die voorbeeld gebruik eth0 as die buitenste koppelvlak en 42 as die identifiseerder, adresse wat jy met jou eie moet vervang.

Bring die toestel op, bevestig dan die identifiseerder wat die kernel aangeteken het voordat jy aan die VPN-opset raak:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Stel nou die verbinding in strongSwan met dieselfde identifiseerder op, want die daemon moet beleide en toestande installeer wat daarna verwys. Stel die plaaslike en afgeleë verkeerskeisers na die reeks wat jy van plan is om te roeteer, en roeteer dan daardie reeks in die toestel in. Die daemon-opset en die roetertabel moet oor beide die identifiseerder en die bestemmings saamstem, en nie een lewer die ander nie.

Hou IKE en ESP uit die tonnelroete

'n Verstekroete wat in die XFRM-toestel in wys, vang die ingekapselde pakkette sowel as die verkeer wat hulle dra. Die resultaat is 'n lus: die poort wag probeer sy eie ESP deur die tonnel stuur wat ESP veronderstel is om te bou.

Die oplossing is 'n meer spesifieke roete vir die eweknie se buitenste adres deur die fisiese koppelvlak, wat die verstek wen omdat dit meer bisse pas. Merkgebaseerde roetering doen dieselfde werk wanneer verskeie tonnele 'n tabel deel, en strongSwan dokumenteer beide benaderings vir roete-gebaseerde ontplooiings.

Wat jy ook al kies, verifieer dat die buitenste pakket ongekapsuleerd vertrek. 'n Vinnige toets is om die eweknie se buitenste adres te ping nadat die tonnel op is; as dit misluk terwyl die koppelvlak op is, vermoed vangs eerder as bereikbaarheid. Dieselfde redenasie geld vir die IKE-poort, want die daemon se eie UDP-verkeer moet nie in die toestel ingeroeteer word wat hy probeer vestig nie.

Kontroleer tellers op twee plekke voordat jy enkripsie blameer

Koppelvlak-tellers en toestandstellers meet verskillende stadiums. Pakkette wat in die toestel ingeroeteer word, verhoog die toestel selfs wanneer geen toestand pas nie, terwyl die toestandstellers net beweeg vir verkeer wat werklik ingekapsel is.

Lees beide, lees dan die daemon se siening van die kind-assosiasie:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Toestel-tellers wat styg met leë toestand-uitset beteken roetering werk en beleid pas nie, gewoonlik 'n identifiseerder- of keiserfout. Toestandstellers wat styg terwyl die afgeleë kant niks rapporteer nie, beteken die pakkette vertrek maar kom nie aan nie of faal verifikasie, wat op die pad of die eweknie-opset dui. 'n Gelyste kind met nul verkeer is 'n keiserprobleem aan een kant, nie 'n stukkende syfer nie.

Besluit wie die roetes installeer

Twee eienaars vir een roetertabel is die gewone oorsaak van flappend. As die daemon roetes outomaties installeer, moet jou netwerkbestuurder nie ook 'n verstekroete deur dieselfde toestel installeer nie, en 'n handmatige roete wat deur 'n opstartskrip bygevoeg is, sal verwyder word die volgende keer wanneer die daemon herkonfigureer.

Kies een eienaar en skryf dit neer. Wanneer die daemon roetes besit, hou die opstartskrip uit die tabel en laat die verbindingsdefinisie die verkeerskeisers beskryf. Wanneer die netwerkbestuurder dit besit, skakel outomatiese installasie af en aanvaar dat die daemon nie 'n ontbrekende roete by herverbinding sal herstel nie.

Stuur- en firewallreëls is 'n aparte besluit bo-op dit, want 'n poort wat ander gashere se verkeer deurlaat, het beide nodig. Roete-gebaseerde IPsec maak daardie verkeer maklik om met gewone roeteringsgereedskap uit te druk; dit maak die beleidslaag nie opsioneel nie.