Hvorfor er undernettet bak en OpenVPN-klient utilgjengelig?

Ping til serverens tunneladresse lykkes, klientens egen rutetabell ser riktig ut, og LAN-et bak den klienten er fortsatt utilgjengelig. Klientens rutetabell ser korrekt ut, serveren har en rute mot tunnelen, og pakkene forsvinner fortsatt. Det er det klassiske symptomet på en layer-3-tunnel som ikke vet at en av klientene også er en gateway.

Et tun-grensesnitt har ingen neste hopp per klient. Kjernen ser ett grensesnitt med mange peers, så beslutningen om hvilken klient som skal motta en pakke til et eksternt LAN, må tas inne i OpenVPN-prosessen. Den beslutningen konfigureres med iroute, og uten den har pakken ingen vei videre.

Serveren ruter etter klient, ikke etter grensesnitt

Når serveren må sende en pakke til en klients tunneladresse, er svaret entydig: adressen tilhører den klientens sesjon. Når destinasjonen er et helt undernett bak den klienten, tilhører adressen ingen serveren kjenner, og kjerneruten til tunnelen sier bare "ut dette grensesnittet", uten å si hvilken peer.

OpenVPN løser det med en intern rutetabell som knytter et destinasjonsprefiks til en bestemt klient. Tabellen bygges av iroute-oppføringer, derfor er en vanlig rute på serververten ikke nok. Kjerneruten bringer pakken til tunellgrensesnittet; den interne koblingen avgjør hvilken sesjon som mottar den. Det er også derfor reparasjonen aldri dukker opp i kjernens ruteutskrift.

Mangler koblingen, kommer pakken til serveren, samsvarer med tunnelruten og blir forkastet fordi ingen klient gjør krav på destinasjonen. Ingenting logger en ren feil, derfor ser feilen ut som et stille svart hull i stedet for en rutingsløyfe.

Skrive iroute-oppføringen som navngir klienten

iroute bor i en klientspesifikk konfigurasjonsfil, ikke i serverens hovedkonfigurasjon. Pek serveren mot en katalog med alternativet client-config-dir, opprett deretter en fil hvis navn er klientens sertifikat-common name, og legg prefikset inn i den.

For en filial der LAN-et er 10.20.0.0/24 og sertifikatets common name er branch-router, inneholder filen på den stien en linje som iroute 10.20.0.0 255.255.255.0. Hovedkonfigurasjonen trenger bare katalogvalget; prefikset bor hos klienten.

Common name er den skjøre delen. Et sertifikat utstedt med et annet subject, eller en utrulling som autentiserer brukere med brukernavn mens filen er navngitt etter sertifikatet, gir en fil som aldri leses. Sjekk navnet serveren faktisk rapporterer for sesjonen, og vurder alternativet som får en klient som ikke samsvarer til å feile i stedet for å koble seg stille til uten rutene sine. Å gi filen nytt navn slik at den samsvarer med sertifikatet er en femminutters rettelse som forhindrer en svært lang kveld.

Én klient kan eie flere prefikser. Legg til én iroute-linje per nettverk, og hold listen ved siden av resten av innstillingene til den klienten slik at koblingen forblir reviderbar.

Bygge returveien i begge retninger

Å få pakkene til det eksterne LAN-et er halve jobben. Klienten må også sende trafikken fra det LAN-et inn i tunnelen, noe som vanligvis gjøres ved å skyve en rute til klienten: en linje som push "route 10.8.0.0 255.255.255.0" forteller hver klient hvordan den når nettverket på serversiden. For filialen peker den tilsvarende ruten mot tunnelen for alt den skal nå på serversiden.

Returretningen trenger en eier på den fjerne siden. Der må noen kjenne veien tilbake: en statisk rute på LAN-ruteren som peker VPN-poolen mot serveren, eller adresseoversettelse på serveren før trafikken kommer inn i LAN-et. Den statiske ruten holder originaladressene synlige i logger og tilgangsregler, men krever LAN-eierens samarbeid; oversettelse er selvstendig, men skjuler hvem som faktisk koblet til.

Videresending må være aktivert på serververten. Uten det godtar kjernen pakken fra tunnelen og nekter å sende den videre til LAN-grensesnittet, noe som fra klientens synspunkt ser identisk ut med en manglende iroute.

Sjekke tilgjengelighet med de riktige probene

Test i lag i stedet for å pinge den fjerne enden og gjette. Fra serveren, sjekk at den interne koblingen for prefikset finnes og at kjerneruten peker mot tunnelen. Fra klienten, bekreft at den skyvede ruten er installert og at standardveien dens til LAN-adressen er tunnelen.

Se deretter på pakkene. En opptak på tunellgrensesnittet viser om serveren overfører mot klienten, og et opptak på LAN-grensesnittet viser om den videresender. Hvis det første viser pakker og det andre ingenting, er problemet videresending eller et filter; hvis ingen av dem viser noe, feilet oppslaget tidligere.

To servere forbundet med en tunnel gjentar den samme regelen på begge sider: hver trenger en iroute for den andres pool, og hver trenger ruten og videresendingen som gjør veien symmetrisk. Ruting og policy er separate spørsmål her. Ruting bestemmer hvor en pakke kan gå, mens en FORWARD-regel bestemmer om den får, så en klient med to iroute-linjer når begge prefiksene med mindre et filter sier noe annet.