Varför går det inte att nå subnätet bakom en OpenVPN-klient?
OpenVPN kan inte gissa vilken klient som äger ett fjärr-LAN. En iroute-post i klientens fil, en returrutt och vidarebefordran gör subnätet nåbart.
Ping till serverns tunneladress lyckas, klientens egen rutttabell ser rätt ut, och LAN:et bakom den klienten är fortfarande onåbart. Klientens rutttabell ser korrekt ut, servern har en rutt mot tunneln, och paketen försvinner ändå. Det är det klassiska symptomet på en layer-3-tunnel som inte vet att en av dess klienter också är en gateway.
Ett tun-gränssnitt har ingen nästa hopp per klient. Kärnan ser ett enda gränssnitt med många parter, så beslutet om vilken klient som ska ta emot ett paket för ett fjärr-LAN måste fattas inne i OpenVPN-processen. Det beslutet konfigureras med iroute, och utan det har paketet ingenstans att ta vägen.
Servern routar per klient, inte per gränssnitt
När servern behöver skicka ett paket till en klients tunneladress är svaret entydigt: adressen tillhör den klientens session. När destinationen är ett helt subnät bakom den klienten tillhör adressen ingen som servern känner, och kärnans rutt till tunneln säger bara "ut genom detta gränssnitt", utan att ange vilken part.
OpenVPN löser detta med en intern rutttabell som knyter ett destinationsprefix till en specifik klient. Tabellen byggs av iroute-poster, därför räcker inte en vanlig rutt på servervärden. Kärnans rutt för paketet till tunnelgränssnittet; den interna kopplingen avgör vilken session som tar emot det. Det är också därför reparationen aldrig dyker upp i kärnans ruttutskrift.
Saknas kopplingen kommer paketet till servern, matchar tunnelrutten och släpps eftersom ingen klient gör anspråk på destinationen. Ingenting loggar ett rent fel, därför ser felet ut som ett tyst svart hål snarare än en routingloop.
Skriva iroute-posten som namnger klienten
iroute bor i en klientspecifik konfigurationsfil, inte i serverns huvudkonfiguration. Rikta servern mot en katalog med alternativet client-config-dir, skapa sedan en fil vars namn är klientens certifikat-common name och lägg prefixet i den.
För en filial vars LAN är 10.20.0.0/24 och vars certifikat-common name är branch-router innehåller filen på den sökvägen en rad som iroute 10.20.0.0 255.255.255.0. Huvudkonfigurationen behöver bara katalogalternativet; prefixet bor hos klienten.
Common name är den ömtåliga delen. Ett certifikat utfärdat med ett annat subject, eller en utrullning som autentiserar användare med användarnamn medan filen är namngiven efter certifikatet, ger en fil som aldrig läses. Kontrollera namnet som servern faktiskt rapporterar för sessionen, och överväg alternativet som får en icke matchande klient att misslyckas i stället för att tyst ansluta utan sina rutter. Att byta namn på filen så att den matchar certifikatet är en femminutersrättelse som förhindrar en mycket lång kväll.
En klient kan äga flera prefix. Lägg till en iroute-rad per nätverk och håll listan bredvid resten av den klientens inställningar så att kopplingen förblir granskningsbar.
Bygga returvägen i båda riktningarna
Att få paketen till fjärr-LAN:et är halva jobbet. Klienten måste också skicka det nätverkets trafik in i tunneln, vilket vanligtvis görs genom att trycka en rutt till klienten: en rad som push "route 10.8.0.0 255.255.255.0" talar om för varje klient hur den når nätverket på serversidan. För filialen pekar den motsvarande rutten mot tunneln för allt den ska nå på serversidan.
Returriktningen behöver en ägare på den bortre sidan. Där måste någon känna vägen tillbaka: en statisk rutt på LAN-routern som pekar VPN-poolen mot servern, eller adressöversättning på servern innan trafiken kommer in i LAN:et. Den statiska rutten håller originaladresserna synliga i loggar och åtkomstregler, men kräver LAN-ägarens samarbete; översättning är självständig men döljer vem som faktiskt anslöt.
Vidarebefordran måste vara aktiverad på servervärden. Utan det accepterar kärnan paketet från tunneln och vägrar skicka vidare det till LAN-gränssnittet, vilket ur klientens synvinkel ser identiskt ut med en saknad iroute.
Kontrollera nåbarhet med rätt prober
Testa i lager i stället för att pinga den bortre änden och gissa. Från servern, kontrollera att den interna kopplingen för prefixet finns och att kärnans rutt pekar mot tunneln. Från klienten, bekräfta att den tryckta rutten är installerad och att dess standardväg till LAN-adressen är tunneln.
Titta sedan på paketen. En avlyssning på tunnelgränssnittet visar om servern sänder mot klienten, och en avlyssning på LAN-gränssnittet visar om den vidarebefordrar. Om den första visar paket och den andra ingenting är problemet vidarebefordran eller ett filter; om ingen av dem visar något misslyckades sökningen tidigare.
Två servrar sammanbundna med en tunnel upprepar samma regel på båda sidor: var och en behöver en iroute för den andras pool, och var och en behöver rutten och vidarebefordran som gör vägen symmetrisk. Routing och policy är separata frågor här. Routing avgör vart ett paket kan gå, medan en FORWARD-regel avgör om det får, så en klient med två iroute-rader når båda prefixen om inte ett filter säger annat.