To OpenVPN-tunneller på én Linux-vært: hvem ejer ruten?

To profiler er forbundet, og den ene bærer stille trafik beregnet til den anden. En Linux-vært kan køre begge OpenVPN-klienter samtidig uden problemer. Det, den ikke kan, er at beslutte for dig, hvilken proces der må gøre krav på hvilket præfiks. Den beslutning skal træffes, før den anden tunnel kommer op, ikke efter en ressource holder op med at svare.

Start med det arbejde, den anden forbindelse skal udføre

Et kontor, der kan nås via én profil, og et laboratorium, der kan nås via en anden, kræver begge tunneller oppe og ingen af dem gøre krav på alt. En enkelt stædig applikation, der skal ud gennem den anden profil, har brug for en politikregel i stedet for en anden standardrute. En reserveforbindelse har kun brug for én tunnel ad gangen, så reserven bør ikke starte med maskinen.

Det er tre forskellige konfigurationer, og de bliver forvekslet, fordi alle tre begynder ens: en anden profil og en vellykket forbindelse. Skriv den tilsigtede ordning ned først, og konfigurer derefter mod den. Én sætning om hensigten sparer en time med pakkefangst.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Den første kommando viser de kørende instanser, inklusive dem, der er startet manuelt uden for manageren. Den anden udskriver det aktuelle standardkrav, og det er den tilstand, du senere skal forklare.

Overlappende puljer brækker før routing gør

To servere uddeler gerne adresser fra den samme 10.8.0.0/24. Klienten holder så to grænseflader inden for ét præfiks uden noget, der siger, hvilken destination der hører til hvilken, og den resulterende adfærd ligner en routingfejl, men er i virkeligheden en nummereringsfejl. At omnummerere en pulje koster én konfigurationsændring; hver efterfølgende routingomvej koster en weekend. Kontroller puljen, før du tilføjer en rute til den.

Kig også på det lokale LAN. Et hjemme-LAN nummereret 192.168.1.0/24, som en tunnel også eksponerer, giver den samme tvetydighed, og symptomet er et værtsnavn, der opløses, mens forbindelsen aldrig fuldføres. Det ligner en navneopløsningsfejl, indtil du udskriver ruterne.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Sammenlign begge output med de to serverkonfigurationer, før du rører klienten. Hvis præfikserne overlapper, så stop og omnummerer, for ingen mængde genstart vil adskille dem.

Giv hver profil sin egen enhed og hvert præfiks en ejer

Hver profil får sit eget instansnavn og sin egen konfigurationsfil, så instansen office indlæser office.conf, mens den, der hedder lab, indlæser lab.conf. Bekræft den mapping gennem tjenestemanageren i stedet for at stole på en mappevisning, da en drop-in kan ændre, hvilken fil der indlæses. Forkert mapping betyder, at du tuner den profil, der ikke kører.

Afgør derefter, hvem der installerer ruter. Når serverne skubber inkompatible sæt, skal du enten afvise skubbet og selv liste præfikserne, eller lade én profil beholde standarden og styre den anden med politikregler. To processer, der begge installerer en standard, ender med en tavs vinder og ingen skriftlig registrering af beslutningen.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Den første viser enheden med enhver tilsidesættelse, der ændrer dens argumenter. Den anden viser, om profilen overhovedet accepterer skubbede ruter, og det er kontakten, der bestemmer alt nedstrøms.

Mærker holder svar på den grænseflade, de kom fra

Når hver tunnel betjener forskellige kilder, kan et svar forlade via det forkerte link, og forbindelsen dør efter den første pakke. Det mønster, der holder, er at markere ankommende pakker efter inputgrænseflade, genskabe mærket på svaret og give hvert mærke en tabel med sin egen standardgateway.

Løs reverse-path-filtrering skal normalt lempes for de berørte grænseflader, fordi et svar med rette ankommer via et link, som hovedtabellen aldrig ville vælge. Hold mærkerne snævre, så de aldrig fanger tunnellernes egen krypterede trafik, hvilket ville sende tunnellen gennem sig selv.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Læs de eksisterende regler, før du tilføjer en mere. Dublerede prioriteter og glemte tabeller er den sædvanlige grund til, at en mærkepolitik ser ud til slet ikke at have nogen effekt.

Bevis isoleringen ved at stoppe ét link

Med begge tunneller oppe skal du registrere hver grænsefladeadresse, ruten til én vært bag hver tunnel og den vej, en urelateret destination tager. Spørg kernen om opslaget i stedet for at læse en enkelt tabel, fordi én tabel aldrig viser den endelige beslutning.

Stop derefter én instans, og se dens grænseflade og ruter forsvinde, mens den anden fortsætter. Et brud i den overlevende betyder, at de to stadig deler et enhedsnavn, en rute eller en firewallregel, som ingen har skilt ad.

Bring den stoppede profil tilbage, og gentag de samme kontroller. Når en tunnel kun overlever den første start efter en genstart, ser du en livscyklusfejl og ikke et routingdesign.