OpenVPN iroute eller kjernerute: hvilken mangler?

En pakke til 10.77.20.0/24 tar to separate beslutninger på en OpenVPN-server: operativsystemet må levere den til VPN-grensesnittet, og OpenVPN må vite hvilken tilkoblet klient som eier det prefikset. En manglende kjernerute slipper den før tunnelen, en manglende peerrute slipper den etterpå. De to feilene ser identiske ut fra det fjerne LAN-et, og å diagnostisere hvilken du har krever én kommando på hver side.

I den klassiske datastien i brukerrommet bringer kjerneruten pakken inn i tunnelprosessen, og iroute forteller den prosessen hvilken peer som skal motta den. Ingen av dem erstatter den andre, og en konfigurasjon med bare én av dem vil se rimelig ut helt til den første ping-en.

To beslutninger, ikke én rute

Se for deg en forbindelse mellom to steder der 10.77.20.0/24 ligger bak én enkelt klient. Serverens kjernerute, for eksempel ip route add 10.77.20.0/24 dev tun0, sender samsvarende pakker til tunneleenheten. Deretter slår OpenVPN opp i sin egen interne tabell, bygget av iroute-oppføringer i klientens konfigurasjonskatalog, for å avgjøre hvilken peer-forbindelse som mottar dem. Uten kjerneruten når pakken aldri prosessen, og uten peerruten når den prosessen og kommer ingen vei.

Den todelingen er lett å glemme, fordi én ruttelinje i en klientprofil kan se ut som den gjør begge jobbene. Det gjør den ikke: å dytte en rute forteller klientene hva de skal sende gjennom tunnelen, mens iroute forteller serveren hvem som eier et adresseområde bak en klient. De bor i ulike filer, leses av ulike sider og feiler i motsatte retninger.

Hvor iroute hører hjemme, og hva den sier

Oppføringen hører i en fil per klient oppkalt etter klientens common_name, under client-config-dir, som iroute 10.77.20.0/24. Filnavnsamsvaret er ikke kosmetisk: OpenVPN slår opp den autentiserte identiteten og leser filen med nøyaktig det navnet, så en fil som heter site-a virker bare for en klient hvis fellesnavn er site-a. Legg til ccd-exclusive hvis klienter uten en slik fil skal avvises helt, som er riktig innstilling når hver klient er en stedsgateway. Hold én fil per gateway, og navngi den etter sertifikatsubjektet du faktisk utsteder.

Test oppføringen fra serveren før du klandrer det fjerne LAN-et. Statusfilen lister tilkoblede klienter med fellesnavnene deres, og en server som kjører med --verb 4, logger installasjonen av iroute når peer-en kobler til. Hvis ingenting dukker opp ved tilkobling, ligger filen i feil katalog eller angir feil identitet.

Fellen: filen finnes, identiteten er feil

En iroute som ser riktig ut, men er knyttet til feil peer, koster mer tid enn en manglende fil, fordi alt på disken ser riktig ut. Omdøping av sertifikater, dupliserte fellesnavn og username-as-common-name som endrer den effektive identiteten lager det alle. Kontroller hvilken identitet serveren autentiserte, i stedet for hvilken du forventet: statusutdataene er autoritative, mens filnavnet bare er en oppslagsnøkkel.

En rute kan også overleve eieren sin. Statiske ruter og iroute-oppføringer beskriver et prefiks, ikke en tilgjengelighetsgaranti, så trafikk kan fortsette å bli rutet mot en peer som er frakoblet akkurat nå.

Fullfør stien forbi peer-en

Peer-eierskap er midten av stien, ikke slutten. Klienten må videresende pakker fra tunnelen til sitt eget LAN, noe som betyr at IP-videresending er slått på på den verten og en brannmurregel tillater gjennomgangen. Verter i det fjerne LAN-et trenger en returvei for tunneladressen: enten en rute som peker tilbake mot gatewayen, eller et bevisst NAT-design på klientsiden. Bekreft videresendingsinnstillingen på klienten med sysctl net.ipv4.ip_forward i stedet for å anta en distribusjonsstandard.

Hvis andre VPN-klienter skal nå det undernettet, vokser oppsettet igjen: serveren trenger client-to-client, og de klientene må rute prefikset gjennom tunnelen. Ingenting av det følger av serverens egen rutetabell.

Bekreft én destinasjon fra en ekte kilde i stedet for fra serveren selv. En ping fra en uvedkommende LAN-vert til en vert bak klienten prøver returveien, videresendingsregelen og peer-eierskapet i én bevegelse, mens et vellykket håndtrykk bare beviser identitet. Koble deretter fra den eierpeer-en og noter hva ruten gjør, fordi det svaret er feilmodusen din.