OpenVPN-server och -klient på samma värd: varför klienter faller bort
En värd som både betjänar och själv använder OpenVPN kan hålla sin tunnel uppe medan lokala klienter förlorar svaren. Två saker förklarar det: en delad adresspool och en ny standardrutt.
Lägg till en klientprofil på en maskin som redan kör en VPN-server, och den ursprungliga tjänsten blir det första offret. Den nya tunneln kanske aldrig etableras, eller den kommer upp medan serverns befintliga klienter tyst slutar få svar. Två kollisioner ger båda resultaten: en tunnelpool som redan används, och en standardrutt som den nya klientsidan installerar och som täcker hela tabellen. Ingen av dem ger ett OpenVPN-felmeddelande, och därför läses felet som ett serverproblem.
En maskin, två roller och två oförenliga svar på vart svaren ska ta vägen.
Samma pool, två servrar: vem vinner
Varje serverinstans behöver sitt eget tunnelsubnät. Kopierar man en rad som server 10.8.0.0 255.255.255.0 till den andra konfigurationen får två instanser samma prefix, och resultatet blir antingen en vägran att starta eller en tyst kamp där klienter hos den ena servern får adresser som den andra också anser sig äga. Olika UDP-portar och olika enhetsnamn hjälper inte, eftersom ingen av dem rör adressutrymmet. Ändra den andra poolen och ändra den överallt där rutterna nämner den.
Lista vad som är aktivt innan du redigerar: ip -4 addr show listar tunneleenheterna, ss -lunp listar lyssnarna och systemctl list-units namnger enheterna. En blick på tunneladresserna avgör om poolerna kolliderar.
Vad klientprofilen lägger till i tabellen
Klientsidan skriver rutter så snart den ansluter. redirect-gateway def1 delar standardrutten i 0.0.0.0/1 plus 128.0.0.0/1, båda routade genom den nya enheten, tillsammans med en värdrutt till den avlägsna servern som medvetet är fäst vid det fysiska gränssnittet. Den fästningen finns för att tunneln ska behålla en väg för sin egen transport. Allt annat, inklusive svaren den lokala servern är skyldig sina egna klienter, följer nu den nya standarden och lämnar via den avlägsna förbindelsen.
Så den andra kollisionen är inte en trasig tunnel. Det är en fungerande tunnel på fel plats i tabellen.
Tre sätt att hålla rollerna åtskilda
Den minst ingripande rättelsen håller standardrutten utanför klientprofilen: route-nopull plus explicita route-rader för de avlägsna prefixen, så att den lokala tabellen bara ändras där du bad om det. Nästa steg är en policyregel som undantar det lokala tunnelsubnätet och låter svar till lokala klienter gå ut på det gränssnitt de kom in på, även när en standardrutt finns. Det mest grundliga är ett eget nätverksnamnrum för klientrollen, som tar bort den delade tabellen helt och kostar en andra routningskontext att underhålla.
Vilken väg du än väljer måste undantaget namnge det lokala tunnelsubnätet och inte LAN. Svaret den lokala servern skickar har en tunneladress som destination, så ett LAN-format undantag matchar aldrig det.
Vilken av de två instanserna är skyldig
Stoppa klientinstansen och testa de ursprungliga klienterna igen. Omedelbar återhämtning betyder routning, inte servern. Ta tillbaka klienten och spåra ett enda svar med ip route get som får både en käll- och en måladdres, vilket visar den väg kärnan skulle välja, och titta sedan på det gränssnitt paketen faktiskt använder med tcpdump -ni any port 1194. Serverns statusfil, som skrivs varje par sekunder via status-direktivet, innehåller listan över anslutna klienter och byträknare i båda riktningarna.
Läs de räknarna mot varandra. Trafik som lämnar och aldrig kommer tillbaka är ett routningssvar och inte ett handskakningsproblem.