Två OpenVPN-tunnlar på en Linux-värd: vem äger rutten?

Två profiler är anslutna, och en av dem bär tyst trafik som är avsedd för den andra. En Linux-värd kan köra båda OpenVPN-klienterna samtidigt utan svårighet. Det den inte kan göra är att avgöra åt dig vilken process som får göra anspråk på vilket prefix. Det beslutet måste fattas innan den andra tunneln kommer upp, inte efter att en resurs slutat svara.

Börja med jobbet som den andra länken måste göra

Ett kontor som nås via en profil och ett labb som nås via en annan behöver båda tunnlarna uppe och ingen av dem som kräver allt. En enda envis applikation som måste ut genom den andra profilen behöver en policyregel i stället för en andra standardrutt. En standby-länk behöver bara en tunnel igång åt gången, så reserven bör inte starta med maskinen.

Det är tre olika konfigurationer, och de blandas ihop eftersom alla tre börjar på samma sätt: en andra profil och en lyckad anslutning. Skriv ned den avsedda ordningen först och konfigurera sedan mot den. En mening om avsikten sparar en timme paketinsamling.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Det första kommandot listar de instanser som körs, inklusive de som startats manuellt utanför hanteraren. Det andra skriver ut det aktuella standardanspråket, och det är tillståndet du senare måste förklara.

Överlappande pooler går sönder innan routingen gör det

Två servrar delar gärna ut adresser ur samma 10.8.0.0/24. Klienten har då två gränssnitt inom ett prefix utan något som säger vilken destination som hör till vilken, och beteendet som följer ser ut som ett routingfel men är egentligen ett numreringsfel. Att numrera om en pool kostar en konfigurationsändring; varje senare routingkringgång kostar en helg. Kontrollera poolen innan du lägger till en rutt för den.

Titta också på det lokala LAN:et. Ett hem-LAN numrerat 192.168.1.0/24 som en tunnel också exponerar ger samma tvetydighet, och symtomet är ett värdnamn som löses upp medan anslutningen aldrig fullbordas. Det ser ut som ett namnmatchfel tills du skriver ut rutterna.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Jämför båda utdata med de två serverkonfigurationerna innan du rör klienten. Om prefixen överlappar, stoppa och numrera om, för ingen mängd omstarter kommer att skilja dem.

Ge varje profil sin egen enhet och varje prefix en ägare

Varje profil får sitt eget instansnamn och sin egen konfigurationsfil, så instansen office läser in office.conf medan den som heter lab läser in lab.conf. Bekräfta den mappningen via tjänstehanteraren i stället för att lita på en kataloglista, eftersom en drop-in kan ändra vilken fil som läses in. Fel mappning betyder att du justerar profilen som inte körs.

Bestäm sedan vem som installerar rutter. När servrarna pushar inkompatibla uppsättningar, antingen avvisa pushen och lista prefixen själv, eller låt en profil behålla standarden och styra den andra med policyregler. Två processer som båda installerar en standard slutar med en tyst vinnare och utan skriftlig registrering av beslutet.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Den första visar enheten med varje överstyrning som ändrar dess argument. Den andra visar om profilen över huvud taget accepterar pushade rutter, och det är strömbrytaren som avgör allt nedströms.

Markeringar håller svar på det gränssnitt de kom från

När varje tunnel betjänar olika källor kan ett svar gå ut via fel länk och anslutningen dör efter det första paketet. Mönstret som håller är att markera ankommande paket efter ingångsgränssnitt, återställa markeringen på svaret och ge varje markering en tabell med sin egen standardgateway.

Lös omvänd sökvägsfiltrering måste vanligtvis lättas för de berörda gränssnitten, eftersom ett svar lagligt anländer via en länk som huvudtabellen aldrig skulle välja. Håll markeringarna smala så att de aldrig fångar tunnlarnas egen krypterade trafik, vilket skulle skicka tunneln genom sig själv.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Läs de befintliga reglerna innan du lägger till en till. Dubblerade prioriteringar och glömda tabeller är det vanliga skälet till att en markeringspolicy verkar helt utan effekt.

Bevisa isolering genom att stoppa en länk

Med båda tunnlarna uppe, registrera varje gränssnittsadress, rutten till en värd bakom varje tunnel och den väg en orelaterad destination tar. Fråga kärnan om uppslaget i stället för att läsa en enda tabell, eftersom en tabell aldrig visar det slutliga beslutet.

Stoppa sedan en instans och se dess gränssnitt och rutter försvinna medan den andra fortsätter. Ett brott i den överlevande betyder att de två fortfarande delar ett enhetsnamn, en rutt eller en brandväggsregel som ingen har skilt.

Ta tillbaka den stoppade profilen och upprepa samma kontroller. När en tunnel bara överlever den första starten efter en omstart, tittar du på ett livscykelfel och inte en routingdesign.