OpenVPN-tenar og -klient på same vert: kvifor klientar fell ut

Legg til ein klientprofil på ei maskin som alt køyrer ein VPN-tenar, og den opphavlege tenesta blir det første offeret. Den nye tunnelen blir kanskje aldri etablert, eller han kjem opp medan dei eksisterande klientane til tenaren stille sluttar å få svar. To kollisjonar gjev begge resultata: ein tunnelpool som alt er i bruk, og ei standardrute som den nye klienthalvdelen installerer og som dekkjer heile tabellen. Ingen av dei gjev ei OpenVPN-feilmelding, og difor blir feilen lesen som eit tenarproblem.

Éi maskin, to roller og to uforseinelege svar på kvar svara skal gå.

Same pool, to tenarar: kven vinn

Kvar tenarinstans treng sitt eige tunnelsubnett. Kopierer ein ei linje som server 10.8.0.0 255.255.255.0 inn i den andre konfigurasjonen, får to instansar same prefiks, og resultatet er anten eit avslag på å starte eller ein stille konkurranse der klientar hos den eine tenaren får adresser som den andre òg meiner å eige. Ulike UDP-portar og ulike einingnamn hjelper ikkje, fordi ingen av dei rører adresserommet. Bytt den andre poolen, og bytt han overalt der rutene nemner han.

List opp kva som er aktivt før du redigerer: ip -4 addr show listar tunneleiningane, ss -lunp listar lyttarane, og systemctl list-units namngjev einingane. Eitt blikk på tunneladressene avgjer om poolane kolliderer.

Kva klientprofilen legg til i tabellen

Klienthalvdelen skriv ruter så snart han koplar til. redirect-gateway def1 deler standardruta i 0.0.0.0/1 pluss 128.0.0.0/1, begge ruta gjennom den nye eininga, saman med ei vertsrute til den fjerne tenaren som med vilje er fest til det fysiske grensesnittet. Den festinga finst for at tunnelen skal halde ein veg for sin eigen transport. Alt anna, inkludert svara den lokale tenaren skuldar sine eigne klientar, følgjer no den nye standarden og går ut via den fjerne sambindinga.

Så den andre kollisjonen er ikkje ein øydelagd tunnel. Det er ein fungerande tunnel på feil stad i tabellen.

Tre måtar å halde rollene frå kvarandre

Den minst inngripande rettinga held standardruta utanfor klientprofilen: route-nopull pluss eksplisitte route-linjer for dei fjerne prefiksa, slik at den lokale tabellen berre blir endra der du bad om det. Neste steg er ei policyregel som unntek det lokale tunnelsubnettet, slik at svar til lokale klientar går ut på grensesnittet dei kom inn på, sjølv når ei standardrute finst. Det grundigaste er eit eige nettverksnamnerom for klientrolla, som fjernar den delte tabellen heilt og kostar ein ekstra rutekontekst å vedlikehalde.

Kva veg du enn vel, må unntaket namngje det lokale tunnelsubnettet og ikkje LAN-et. Svaret den lokale tenaren sender har ei tunneladresse som mål, så eit LAN-forma unntak passar aldri på det.

Kva av dei to instansane som er skuld i det

Stopp klientinstansen og test dei opphavlege klientane på nytt. Umiddelbar attoppretting betyr ruting, ikkje tenaren. Ta klienten tilbake og spor eitt enkelt svar med ip route get som får både ei kjelde- og ei måladdresse, noko som viser vegen kjernen ville velje, og sjå deretter på grensesnittet pakkane faktisk brukar med tcpdump -ni any port 1194. Statusfila til tenaren, som blir skriven kvart par sekund gjennom status-direktivet, inneheld lista over tilkopla klientar og bytteteljarar i begge retningar.

Les teljarane mot kvarandre. Trafikk som går ut og aldri kjem tilbake, er eit ruteringssvar og ikkje eit handtrykkproblem.