OpenVPN-server og -klient på samme vært: hvorfor klienter falder af

Tilføj en klientprofil til en maskine, der allerede kører en VPN-server, og den oprindelige tjeneste bliver det første offer. Den nye tunnel bliver måske aldrig oprettet, eller den kommer op, mens serverens eksisterende klienter stille holder op med at få svar. To kollisioner giver begge resultater: en tunnelpulje, der allerede er i brug, og en standardrute, som den nye klienthalvdel installerer, og som dækker hele tabellen. Ingen af dem giver en OpenVPN-fejlmeddelelse, og derfor læses fejlen som et serverproblem.

En maskine, to roller og to uforenelige svar på, hvor svarene skal hen.

Samme pulje, to servere: hvem vinder

Hver serverinstans har brug for sit eget tunnelsubnet. Kopierer man en linje som server 10.8.0.0 255.255.255.0 ind i den anden konfiguration, får to instanser samme præfiks, og resultatet er enten et afslag på at starte eller en stille konkurrence, hvor klienter hos den ene server får adresser, som den anden også mener at eje. Forskellige UDP-porte og forskellige enhedsnavne hjælper ikke, fordi ingen af dem rører adresserummet. Skift den anden pulje, og skift den overalt, hvor ruterne nævner den.

List op, hvad der er aktivt, før du redigerer: ip -4 addr show viser tunnelegnhederne, ss -lunp viser lytterne, og systemctl list-units navngiver enhederne. Et blik på tunneladresserne afgør, om puljerne kolliderer.

Hvad klientprofilen tilføjer til tabellen

Klienthalvdelen skriver ruter, så snart den forbinder. redirect-gateway def1 deler standardruten i 0.0.0.0/1 plus 128.0.0.0/1, som begge routes gennem den nye enhed, sammen med en værtsrute til den fjerne server, der bevidst er låst til den fysiske grænseflade. Den lås findes, så tunnelen beholder en vej til sin egen transport. Alt andet, herunder de svar, den lokale server skylder sine egne klienter, følger nu den nye standard og forlader via det fjerne link.

Så den anden kollision er ikke en brudt tunnel. Det er en fungerende tunnel på det forkerte sted i tabellen.

Tre måder at holde rollerne adskilt

Den mindst indgribende rettelse holder standardruten ude af klientprofilen: route-nopull plus eksplicitte route-linjer for de fjerne præfikser, så den lokale tabel kun ændres, hvor du bad om det. Næste skridt er en politikregel, der fritager det lokale tunnelsubnet, så svar til lokale klienter forlader den grænseflade, de ankom på, selv mens en standardrute findes. Den mest grundige er et separat netværksnavnerum til klientrollen, som fjerner den delte tabel helt og koster en ekstra routingkontekst at vedligeholde.

Uanset hvilken vej du vælger, skal undtagelsen navngive det lokale tunnelsubnet og ikke LAN'et. Det svar, den lokale server sender, har en tunneladresse som destination, så en LAN-formet undtagelse matcher aldrig.

Hvilken af de to instanser er skyldneren

Stop klientinstansen, og test de oprindelige klienter igen. Øjeblikkelig genopretning betyder routing, ikke serveren. Bring klienten tilbage, og spor et enkelt svar med ip route get, der får både en kilde- og en destinationsadresse, hvilket viser den vej, kernen ville vælge, og se så på den grænseflade, pakkerne faktisk bruger, med tcpdump -ni any port 1194. Serverens statusfil, der skrives hvert par sekunder via status-direktivet, indeholder listen over tilsluttede klienter og byttetællere i begge retninger.

Læs de tællere mod hinanden. Trafik, der forlader og aldrig vender tilbage, er et routing-svar snarere end et håndtryksproblem.