To OpenVPN-tunneler på én Linux-vert: hvem eier ruten?

To profiler er tilkoblet, og én av dem bærer stille trafikk som er ment for den andre. En Linux-vert kan kjøre begge OpenVPN-klientene samtidig uten problemer. Det den ikke kan gjøre, er å avgjøre for deg hvilken prosess som har lov til å kreve hvilket prefiks. Den avgjørelsen må tas før den andre tunnelen kommer opp, ikke etter at en ressurs slutter å svare.

Begynn med jobben den andre lenken skal gjøre

Et kontor som nås via én profil og et laboratorium som nås via en annen trenger begge tunnelene oppe og ingen av dem som krever alt. En enkelt sta applikasjon som må ut gjennom den andre profilen trenger en policyregel i stedet for en andre standardrute. En reserveforbindelse trenger bare én tunnel som kjører om gangen, så reserveforbindelsen bør ikke starte med maskinen.

Dette er tre forskjellige konfigurasjoner, og de blandes sammen fordi alle tre begynner på samme måte: en andre profil og en vellykket tilkobling. Skriv ned den tiltenkte ordningen først, og konfigurer deretter mot den. Én setning om hensikten sparer en time med pakkefangst.

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

Den første kommandoen viser instansene som kjører, inkludert dem som er startet manuelt utenfor behandleren. Den andre skriver ut det gjeldende standardkravet, som er tilstanden du senere må forklare.

Overlappende puljer ryker før rutingen gjør det

To servere deler gjerne ut adresser fra samme 10.8.0.0/24. Klienten har da to grensesnitt innenfor ett prefiks uten noe som sier hvilken destinasjon som hører til hvilket, og atferden som følger ser ut som en rutefeil, men er egentlig en nummereringsfeil. Å omnummerere en pulje koster én konfigurasjonsendring; hver senere ruteomvei koster en helg. Sjekk puljen før du legger til en rute for den.

Se også på det lokale LAN-et. Et hjemme-LAN nummerert 192.168.1.0/24 som én tunnel også eksponerer, gir samme tvetydighet, og symptomet er et vertsnavn som løses opp mens tilkoblingen aldri fullføres. Det ser ut som en navneoppløsningsfeil helt til du skriver ut rutene.

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

Sammenlign begge utdataene med de to serverkonfigurasjonene før du rører klienten. Hvis prefiksene overlapper, stopp og omnummerer, for ingen mengde omstart vil skille dem.

Gi hver profil sin egen enhet og hvert prefiks en eier

Hver profil får sitt eget instansnavn og sin egen konfigurasjonsfil, så instansen office laster office.conf mens den som heter lab laster lab.conf. Bekreft den koblingen gjennom tjenestebehandleren i stedet for å stole på en katalogoppføring, siden en drop-in kan endre hvilken fil som lastes. Feil kobling betyr at du justerer profilen som ikke kjører.

Avgjør deretter hvem som installerer ruter. Når serverne pusher inkompatible sett, må du enten avvise pushen og liste prefiksene selv, eller la én profil beholde standarden og styre den andre med policyregler. To prosesser som begge installerer en standard, ender med en stille vinner og ingen skriftlig registrering av avgjørelsen.

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

Den første viser enheten med enhver overstyring som endrer argumentene. Den andre viser om profilen i det hele tatt godtar pushede ruter, og det er bryteren som avgjør alt videre.

Merker holder svar på grensesnittet de kom fra

Når hver tunnel betjener forskjellige kilder, kan et svar gå ut via feil lenke og tilkoblingen dør etter den første pakken. Mønsteret som holder, er å merke ankommende pakker etter inngangsgrensesnitt, gjenopprette merket på svaret og gi hvert merke en tabell med sin egen standard gateway.

Løs reversert sti-filtrering må vanligvis lempes for de berørte grensesnittene, fordi et svar lovlig ankommer via en lenke som hovedtabellen aldri ville velge. Hold merkene smale så de aldri fanger tunnelenes egen krypterte trafikk, noe som ville sendt tunnelen gjennom seg selv.

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

Les de eksisterende reglene før du legger til en ny. Dupliserte prioriteter og glemte tabeller er den vanlige grunnen til at en merkepolicy ser ut til å ikke ha noen effekt i det hele tatt.

Bevis isolasjon ved å stoppe én lenke

Med begge tunnelene oppe, registrer adressen til hvert grensesnitt, ruten til én vert bak hver tunnel og veien en urelatert destinasjon tar. Spør kjernen om oppslaget i stedet for å lese én enkelt tabell, fordi én tabell aldri viser den endelige avgjørelsen.

Stopp deretter én instans og se grensesnittet og rutene forsvinne mens den andre fortsetter. Et brudd i den overlevende betyr at de to fortsatt deler et enhetsnavn, en rute eller en brannmurregel som ingen har skilt.

Ta den stoppede profilen tilbake og gjenta de samme kontrollene. Når en tunnel bare overlever den første starten etter omstart, ser du en livssyklusfeil og ikke et rutingsdesign.