OpenVPN-server og -klient på samme vert: hvorfor klienter faller ut

Legg til en klientprofil på en maskin som allerede kjører en VPN-server, og den opprinnelige tjenesten blir det første offeret. Den nye tunnelen blir kanskje aldri etablert, eller den kommer opp mens serverens eksisterende klienter stille slutter å få svar. To kollisjoner gir begge resultatene: en tunnelpool som allerede er i bruk, og en standardrute som den nye klienthalvdelen installerer og som dekker hele tabellen. Ingen av dem gir en OpenVPN-feilmelding, og derfor leses feilen som et serverproblem.

Én maskin, to roller og to uforenlige svar på hvor svarene skal gå.

Samme pool, to servere: hvem vinner

Hver serverinstans trenger sitt eget tunnelsubnett. Kopierer man en linje som server 10.8.0.0 255.255.255.0 inn i den andre konfigurasjonen, får to instanser samme prefiks, og resultatet er enten en nektelse på å starte eller en stille konkurranse der klienter hos den ene serveren får adresser som den andre også mener å eie. Ulike UDP-porter og ulike enhetsnavn hjelper ikke, fordi ingen av dem berører adresserommet. Bytt den andre poolen, og bytt den overalt der rutene nevner den.

List opp hva som er aktivt før du redigerer: ip -4 addr show lister opp tunneleenhetene, ss -lunp lister opp lytterne, og systemctl list-units navngir enhetene. Ett blikk på tunneladressene avgjør om poolene kolliderer.

Hva klientprofilen legger til i tabellen

Klienthalvdelen skriver ruter så snart den kobler til. redirect-gateway def1 deler standardruten i 0.0.0.0/1 pluss 128.0.0.0/1, begge rutet gjennom den nye enheten, sammen med en vertsrute til den fjerne serveren som bevisst er festet til det fysiske grensesnittet. Den festingen finnes for at tunnelen skal beholde en vei for sin egen transport. Alt annet, inkludert svarene den lokale serveren skylder sine egne klienter, følger nå den nye standarden og forlater via den fjerne forbindelsen.

Så den andre kollisjonen er ikke en ødelagt tunnel. Det er en fungerende tunnel på feil sted i tabellen.

Tre måter å holde rollene fra hverandre

Den minst inngripende rettelsen holder standardruten utenfor klientprofilen: route-nopull pluss eksplisitte route-linjer for de fjerne prefiksene, slik at den lokale tabellen bare endres der du ba om det. Neste steg er en policyregel som unntar det lokale tunnelsubnettet, slik at svar til lokale klienter går ut på grensesnittet de kom inn på, selv når en standardrute finnes. Det grundigste er et eget nettverksnavnerom for klientrollen, som fjerner den delte tabellen helt og koster en ekstra rutekontekst å vedlikeholde.

Hvilken vei du enn velger, må unntaket navngi det lokale tunnelsubnettet og ikke LAN-et. Svaret den lokale serveren sender har en tunneladresse som mål, så et LAN-formet unntak passer aldri på det.

Hvilken av de to instansene er skyld i det

Stopp klientinstansen og test de opprinnelige klientene på nytt. Umiddelbar gjenoppretting betyr ruting, ikke serveren. Ta klienten tilbake og spor ett enkelt svar med ip route get som får både en kilde- og en måladdresse, noe som viser veien kjernen ville velge, og se deretter på grensesnittet pakkene faktisk bruker med tcpdump -ni any port 1194. Statusfilen til serveren, som skrives hvert par sekunder gjennom status-direktivet, inneholder listen over tilkoblede klienter og byttetellere i begge retninger.

Les tellerne mot hverandre. Trafikk som forlater og aldri kommer tilbake, er et ruteringssvar og ikke et håndtrykksproblem.