Prečo je podsiete za klientom OpenVPN nedostupná?

Pingy na tunelovú adresu servera prechádzajú, vlastná smerovacia tabuľka klienta vyzerá správne a LAN za týmto klientom je stále nedostupná. Smerovacia tabuľka klienta vyzerá korektne, server má trasu smerujúcu do tunela a pakety stále miznú. Je to klasický príznak tunela layer-3, ktorý netuší, že jeden z jeho klientov je zároveň brána.

Rozhranie tun nemá ďalší skok pre jednotlivých klientov. Jadro vidí jedno rozhranie s mnohými partnermi, takže rozhodnutie, ktorý klient má dostať paket pre vzdialenú LAN, sa musí urobiť vnútri procesu OpenVPN. Toto rozhodnutie sa konfiguruje pomocou iroute a bez neho paket nemá kam ísť.

Server smeruje podľa klienta, nie podľa rozhrania

Keď server potrebuje poslať paket na tunelovú adresu klienta, odpoveď je jednoznačná: adresa patrí relácii tohto klienta. Keď je cieľom celá podsiete za týmto klientom, adresa nepatrí nikomu, koho server pozná, a trasa jadra do tunela hovorí len "týmto rozhraním", bez toho, aby určila partnera.

OpenVPN to rieši vnútornou smerovacou tabuľkou, ktorá priraďuje cieľový prefix konkrétnemu klientovi. Táto tabuľka sa zostavuje zo záznamov iroute, preto bežná trasa na hostiteľovi servera nestačí. Trasa jadra dostane paket k tunelovému rozhraniu; vnútorné mapovanie rozhodne, ktorá relácia ho prijme. Preto sa oprava nikdy neobjaví vo výstupe trás jadra.

Ak mapovanie chýba, paket dorazí na server, zodpovedá tunelovej trase a je zahodený, pretože žiadny klient si cieľ nenárokuje. Nič nezapíše čistú chybu, preto porucha vyzerá ako tichá čierna diera, nie ako smerovacia slučka.

Zapísanie záznamu iroute, ktorý pomenuje klienta

iroute žije v konfiguračnom súbore špecifickom pre klienta, nie v hlavnej konfigurácii servera. Nasmerujte server na adresár voľbou client-config-dir, potom vytvorte súbor, ktorého názov je bežný názov certifikátu klienta, a vložte doň prefix.

Pre pobočku, ktorej LAN je 10.20.0.0/24 a ktorej bežný názov certifikátu je branch-router, obsahuje súbor na tejto ceste riadok ako iroute 10.20.0.0 255.255.255.0. Hlavná konfigurácia potrebuje len voľbu adresára; prefix žije u klienta.

Bežný názov je krehká časť. Certifikát vydaný s iným subject, alebo nasadenie, ktoré overuje používateľov podľa používateľského mena, zatiaľ čo súbor je pomenovaný podľa certifikátu, vytvorí súbor, ktorý sa nikdy nečíta. Skontrolujte názov, ktorý server skutočne hlási pre reláciu, a zvážte voľbu, ktorá neodpovedajúcemu klientovi umožní zlyhať namiesto tichého pripojenia bez jeho trás. Premenovanie súboru podľa certifikátu je päťminútová oprava, ktorá zabráni veľmi dlhému večeru.

Jeden klient môže vlastniť niekoľko prefixov. Pridajte jeden riadok iroute pre každú sieť a udržujte zoznam vedľa ostatného nastavenia tohto klienta, aby mapovanie zostalo auditovateľné.

Budovanie spätnej cesty v oboch smeroch

Dostať pakety do vzdialenej LAN je polovica práce. Klient musí tiež posielať premávku tejto LAN do tunela, čo sa zvyčajne robí zatlačením trasy klientovi: riadok ako push "route 10.8.0.0 255.255.255.0" hovorí každému klientovi, ako dosiahnuť sieť na strane servera. Pre pobočku ekvivalentná trasa ukazuje do tunela pre všetko, čo má na strane servera dosiahnuť.

Spätný smer potrebuje vlastníka na vzdialenej strane. Tam musí niekto poznať cestu späť: statická trasa na routeri LAN, ktorá smeruje fond VPN na server, alebo preklad adries na serveri pred vstupom premávky do LAN. Statická trasa udržiava pôvodné adresy viditeľné v protokoloch a prístupových pravidlách, ale vyžaduje spoluprácu vlastníka LAN; preklad je samostatný, ale skrýva, kto sa skutočne pripojil.

Preposielanie musí byť na hostiteľovi servera povolené. Bez neho jadro prijme paket z tunela a odmietne ho odovzdať rozhraniu LAN, čo z pohľadu klienta vyzerá rovnako ako chýbajúci iroute.

Overenie dostupnosti správnymi sondami

Testujte po vrstvách, namiesto pingovania vzdialeného konca a hádania. Zo servera overte, že vnútorné mapovanie pre prefix existuje a že trasa jadra ukazuje do tunela. Z klienta potvrďte, že zatlačená trasa je nainštalovaná a že jeho predvolená cesta k adrese LAN je tunel.

Potom sledujte pakety. Zachytenie na tunelovom rozhraní ukáže, či server vysiela smerom ku klientovi, a zachytenie na rozhraní LAN ukáže, či preposiela. Ak prvé ukazuje pakety a druhé nič, problém je v preposielaní alebo vo filtri; ak ani jedno nič neukazuje, vyhľadanie zlyhalo skôr.

Dva servery spojené tunelom opakujú rovnaké pravidlo na oboch stranách: každý potrebuje iroute pre fond toho druhého a každý potrebuje trasu a preposielanie, ktoré robia cestu symetrickou. Smerovanie a politika sú tu oddelené záležitosti. Smerovanie rozhoduje, kam paket môže ísť, zatiaľ čo pravidlo FORWARD rozhoduje, či smie, takže klient s dvoma riadkami iroute dosiahne oba prefixy, ak filter nehovorí inak.