OpenVPN-server en -client op één host: waarom clients wegvallen

Voeg een clientprofiel toe aan een machine waarop al een VPN-server draait, en de oorspronkelijke dienst is het eerste slachtoffer. De nieuwe tunnel komt misschien nooit tot stand, of hij komt op terwijl de bestaande clients van de server stil geen antwoorden meer krijgen. Twee botsingen leveren beide resultaten op: een tunnelpool die al in gebruik is, en een standaardroute die de nieuwe clienthelft installeert en die de hele tabel dekt. Geen van beide levert een OpenVPN-foutmelding op, en daarom wordt de storing als een serverprobleem gelezen.

Eén machine, twee rollen, en twee onverenigbare antwoorden over waar antwoorden heen moeten.

Dezelfde pool, twee servers: wie wint

Elke serverinstantie heeft een eigen tunnelsubnet nodig. Een regel als server 10.8.0.0 255.255.255.0 naar de tweede configuratie kopiëren geeft twee instanties dezelfde prefix, en de uitkomst is óf een weigering om te starten óf een stille wedstrijd waarin clients van de ene server adressen krijgen die de andere ook als de zijne beschouwt. Verschillende UDP-poorten en verschillende apparaatnamen helpen niet, want geen van beide raakt de adresruimte aan. Wijzig de tweede pool, en wijzig hem overal waar de routes hem noemen.

Inventariseer wat er actief is voordat je iets aanpast: ip -4 addr show toont de tunnelapparaten, ss -lunp toont de luisteraars, en systemctl list-units noemt de units. Eén blik op de tunneladressen beslist of de pools botsen.

Wat het clientprofiel aan de tabel toevoegt

De clienthelft schrijft routes zodra hij verbindt. redirect-gateway def1 splitst de standaardroute in 0.0.0.0/1 plus 128.0.0.0/1, beide via het nieuwe apparaat gerouteerd, samen met een hostroute naar de verre server die bewust aan de fysieke interface is vastgezet. Die pin bestaat zodat de tunnel een pad houdt voor zijn eigen transport. Al het andere, inclusief de antwoorden die de lokale server zijn eigen clients verschuldigd is, volgt nu de nieuwe standaard en vertrekt via de externe verbinding.

De tweede botsing is dus geen kapotte tunnel. Het is een werkende tunnel op de verkeerde plek in de tabel.

Drie manieren om de rollen gescheiden te houden

De minst ingrijpende oplossing houdt de standaardroute buiten het clientprofiel: route-nopull plus expliciete route-regels voor de externe prefixen, zodat de lokale tabel alleen verandert waar je erom vroeg. De volgende stap is een beleidsregel die het lokale tunnelsubnet uitzondert, waardoor antwoorden aan lokale clients via de interface vertrekken waarop ze aankwamen, zelfs als er een standaardroute bestaat. Het grondigst is een aparte netwerknaamruimte voor de clientrol, die de gedeelde tabel volledig weghaalt en een tweede routeringscontext kost om te onderhouden.

Welke weg je ook kiest, de uitzondering moet het lokale tunnelsubnet noemen en niet het LAN. Het antwoord dat de lokale server stuurt heeft een tunneladres als bestemming, dus een uitzondering in LAN-vorm past er nooit op.

Welke van de twee instanties is de schuldige

Stop de clientinstantie en test de oorspronkelijke clients opnieuw. Onmiddellijk herstel betekent routering, niet de server. Breng de client terug en volg één antwoord met ip route get waaraan zowel een bron- als een bestemmingsadres is gegeven, wat het pad toont dat de kernel zou kiezen, en kijk daarna met tcpdump -ni any port 1194 naar de interface die pakketten werkelijk gebruiken. Het statusbestand van de server, elke paar seconden geschreven via de status-directive, bevat de lijst met verbonden clients en bytetellers voor beide richtingen.

Lees die tellers tegen elkaar. Verkeer dat vertrekt en nooit terugkomt is een routeringsantwoord en geen handshake-probleem.