Kvifor er undernettet bak ein OpenVPN-klient utilgjengeleg?

Ping til tunneladressa til tenaren lukkast, klienten si eiga rutetabell ser rett ut, og LAN-et bak den klienten er framleis utilgjengeleg. Rutetabellen til klienten ser korrekt ut, tenaren har ei rute mot tunnelen, og pakkane forsvinn framleis. Det er det klassiske symptomet på ein layer-3-tunnel som ikkje veit at ein av klientane òg er ein gateway.

Eit tun-grensesnitt har ingen neste hopp per klient. Kjernen ser eitt grensesnitt med mange peers, så avgjerda om kva klient som skal ta imot ein pakke til eit eksternt LAN, må takast inne i OpenVPN-prosessen. Den avgjerda blir konfigurert med iroute, og utan ho har pakken ingen veg vidare.

Tenaren rutar etter klient, ikkje etter grensesnitt

Når tenaren må sende ein pakke til tunneladressa til ein klient, er svaret eintydig: adressa høyrer til sesjonen til den klienten. Når destinasjonen er eit heilt undernett bak den klienten, høyrer adressa til ingen som tenaren kjenner, og kjerneruta til tunnelen seier berre "ut dette grensesnittet", utan å seie kva peer.

OpenVPN løyser det med ein intern rutetabell som knyter eit destinasjonsprefiks til ein bestemt klient. Tabellen blir bygd av iroute-oppføringar, difor er ei vanleg rute på tenarverten ikkje nok. Kjerneruta bringer pakken til tunellgrensesnittet; den interne koplinga avgjer kva sesjon som tek imot han. Det er òg difor reparasjonen aldri dukkar opp i ruteutskrifta til kjernen.

Manglar koplinga, kjem pakken til tenaren, samsvarar med tunnelruta og blir forkasta fordi ingen klient krev destinasjonen. Ingenting loggar ein rein feil, difor ser feilen ut som eit stille svart hol i staden for ei rutingsløyfe.

Skrive iroute-oppføringa som namngir klienten

iroute bur i ei klientspesifikk konfigurasjonsfil, ikkje i hovudkonfigurasjonen til tenaren. Peik tenaren mot ein katalog med valet client-config-dir, opprett deretter ei fil der namnet er sertifikat-common name til klienten, og legg prefikset inn i ho.

For ein filial der LAN-et er 10.20.0.0/24 og sertifikatets common name er branch-router, inneheld fila på den stien ei linje som iroute 10.20.0.0 255.255.255.0. Hovudkonfigurasjonen treng berre katalogvalet; prefikset bur hos klienten.

Common name er den skjøre delen. Eit sertifikat utstedt med eit anna subject, eller ei utrulling som autentiserer brukarar med brukarnamn medan fila er namngitt etter sertifikatet, gir ei fil som aldri blir lesen. Sjekk namnet tenaren faktisk rapporterer for sesjonen, og vurder valet som får ein klient som ikkje samsvarar til å feile i staden for å kople seg stille til utan rutene sine. Å gje fila nytt namn slik at ho samsvarar med sertifikatet er ei femminutts retting som hindrar ein svært lang kveld.

Éin klient kan eige fleire prefiks. Legg til éi iroute-linje per nettverk, og hald lista ved sida av resten av innstillingane til den klienten slik at koplinga blir verifiserbar.

Bygge returvegen i begge retningar

Å få pakkane til det eksterne LAN-et er halve jobben. Klienten må òg sende trafikken frå det LAN-et inn i tunnelen, noko som vanlegvis blir gjort ved å skyve ei rute til klienten: ei linje som push "route 10.8.0.0 255.255.255.0" fortel kvar klient korleis han når nettverket på tenarsida. For filialen peikar den tilsvarande ruta mot tunnelen for alt han skal nå på tenarsida.

Returretninga treng ein eigar på den fjerne sida. Der må nokon kjenne vegen tilbake: ei statisk rute på LAN-ruteren som peikar VPN-poolen mot tenaren, eller adresseomsetjing på tenaren før trafikken kjem inn i LAN-et. Den statiske ruta held originaladressene synlege i loggar og tilgangsreglar, men krev samarbeid frå LAN-eigaren; omsetjing er sjølvstendig, men skjuler kven som faktisk kopla til.

Videresending må vere aktivert på tenarverten. Utan det godtek kjernen pakken frå tunnelen og nektar å sende han vidare til LAN-grensesnittet, noko som frå synsvinkelen til klienten ser identisk ut med ein manglande iroute.

Sjekke tilgjenge med dei rette probane

Test i lag i staden for å pinge den fjerne enden og gjette. Frå tenaren, sjekk at den interne koplinga for prefikset finst og at kjerneruta peikar mot tunnelen. Frå klienten, stadfest at den skyvde ruta er installert og at standardvegen hans til LAN-adressa er tunnelen.

Sjå deretter på pakkane. Ein opptak på tunellgrensesnittet viser om tenaren overfører mot klienten, og eit opptak på LAN-grensesnittet viser om han videresender. Viss det første viser pakkar og det andre ingenting, er problemet videresending eller eit filter; viss ingen av dei viser noko, feila oppslaget tidlegare.

To tenarar forbundne med ein tunnel gjer den same regelen om att på begge sider: kvar treng ein iroute for poolen til den andre, og kvar treng ruta og videresendinga som gjer vegen symmetrisk. Ruting og politikk er skilde spørsmål her. Ruting avgjer kvar ein pakke kan gå, medan ein FORWARD-regel avgjer om han får, så ein klient med to iroute-linjer når begge prefiksa med mindre eit filter seier noko anna.