OpenVPN iroute eller kärnroute: vilken saknas?
Servern har en route och trafiken stannar ändå. Det ena vägbeslutet tillhör kärnan, det andra peer-en; ta reda på vilken som saknas och vad du ska kontrollera.
Ett paket till 10.77.20.0/24 fattar två separata beslut på en OpenVPN-server: operativsystemet måste lämna det till VPN-gränssnittet, och OpenVPN måste veta vilken ansluten klient som äger det prefixet. En saknad kärnroute släpper det före tunneln, en saknad peerroute släpper det efteråt. De två felen ser identiska ut från det avlägsna LAN-et, och att diagnostisera vilket du har kräver ett kommando på varje sida.
I den klassiska datavägen i användarutrymmet tar kärnrouten paketet in i tunnelprocessen, och iroute berättar för den processen vilken peer som ska ta emot det. Ingen av dem ersätter den andra, och en konfiguration med bara en av dem ser rimlig ut ända till första ping.
Två beslut, inte en route
Föreställ dig en förbindelse mellan platser där 10.77.20.0/24 ligger bakom en enda klient. Serverns kärnroute, till exempel ip route add 10.77.20.0/24 dev tun0, skickar matchande paket till tunnelemheten. Sedan slår OpenVPN upp i sin egen interna tabell, byggd av iroute-poster i klientens konfigurationskatalog, för att avgöra vilken peerförbindelse som tar emot dem. Utan kärnrouten når paketet aldrig processen, och utan peerroute når det processen och kommer ingenstans.
Den uppdelningen är lätt att glömma, eftersom en enda routelinje i en klientprofil kan se ut att göra båda jobben. Det gör den inte: att trycka ut en route talar om för klienterna vad de ska skicka genom tunneln, medan iroute talar om för servern vem som äger ett adressområde bakom en klient. De bor i olika filer, läses av olika sidor och misslyckas i motsatta riktningar.
Var iroute hör hemma och vad den säger
Posten hör i en fil per klient, namngiven efter klientens common_name, under client-config-dir, som iroute 10.77.20.0/24. Filnamnsmatchningen är inte kosmetisk: OpenVPN slår upp den autentiserade identiteten och läser filen med exakt det namnet, så en fil som heter site-a gäller bara för en klient vars vanliga namn är site-a. Lägg till ccd-exclusive om klienter utan en sådan fil ska avvisas helt, vilket är rätt inställning när varje klient är en platsgateway. Håll en fil per gateway och namnge den efter det certifikatsubjekt du faktiskt utfärdar.
Testa posten från servern innan du skyller på det avlägsna LAN-et. Statusfilen listar anslutna klienter med deras vanliga namn, och en server som körs med --verb 4 loggar installationen av iroute i det ögonblick peer-en ansluter. Om inget dyker upp vid anslutningen ligger filen i fel katalog eller anger fel identitet.
Fällan: filen finns, identiteten är fel
En iroute som ser rätt ut men sitter på fel peer kostar mer tid än en saknad fil, eftersom allt på disken ser rätt ut. Omdöpning av certifikat, dubblerade vanliga namn och username-as-common-name som ändrar den effektiva identiteten skapar allt detta. Kontrollera vilken identitet servern autentiserade i stället för vilken du förväntade dig: statusutdata är auktoritativ, medan filnamnet bara är en uppslagsnyckel.
En route kan överleva sin ägare. Statiska rutter och iroute-poster beskriver ett prefix, inte en tillgänglighetsgaranti, så trafik kan fortsätta att routas mot en peer som just nu är frånkopplad.
Slutför vägen bortom peer-en
Peer-ägarskap är mitten av vägen, inte slutet. Klienten måste vidarebefordra paket från tunneln till sitt eget LAN, vilket innebär att IP-vidarebefordran är påslagen på den värden och att en brandväggsregel tillåter genomfarten. Värdar i det avlägsna LAN-et behöver en returväg för tunneladressen: antingen en route som pekar tillbaka mot gatewayen, eller en medveten NAT-design på klientsidan. Bekräfta vidarebefordringsinställningen på klienten med sysctl net.ipv4.ip_forward i stället för att anta en distributionsstandard.
Om andra VPN-klienter måste nå det subnätet växer upplägget igen: servern behöver client-to-client, och de klienterna måste routa prefixet genom tunneln. Inget av det följer av serverns egen routingtabell.
Verifiera en destination från en riktig källa i stället för från servern själv. En ping från en oberoende LAN-värd till en värd bakom klienten prövar returvägen, vidarebefordringsregeln och peer-ägarskapet i en enda rörelse, medan en lyckad handskakning bara bevisar identitet. Koppla sedan bort den ägande peer-en och notera vad routen gör, eftersom det svaret är ditt felläge.