Waarom is die subnet agter 'n OpenVPN-kliënt onbereikbaar?

Pings na die bediener se tonneladres slaag, die kliënt se eie roetelys lyk reg, en die LAN agter daardie kliënt is steeds onbereikbaar. Die kliënt se eie roetelys lyk korrek, die bediener het 'n roete wat na die tonnel wys, en pakkette verdwyn steeds. Dit is die klassieke simptoom van 'n layer-3-tonnel wat geen idee het dat een van sy kliënte ook 'n poort is nie.

'n tun-koppelvlak het geen volgende sprong per kliënt nie. Die kernel sien een koppelvlak met baie eweknieë, so die besluit oor watter kliënt 'n pakket vir 'n afgeleë LAN moet ontvang, moet binne die OpenVPN-proses geneem word. Daardie besluit word met iroute opgestel, en sonder dit het die pakket nêrens om heen te gaan nie.

Die bediener roeteer per kliënt, nie per koppelvlak nie

Wanneer die bediener 'n pakket na 'n kliënt se tonneladres moet stuur, is die antwoord ondubbelsinnig: die adres hoort by daardie kliënt se sessie. Wanneer die bestemming 'n hele subnet agter daardie kliënt is, behoort die adres aan niemand wat die bediener ken nie, en die kernel se roete na die tonnel sê net "uit hierdie koppelvlak" sonder om te sê watter eweknie.

OpenVPN los dit op met 'n interne roetelys wat 'n bestemmingsvoorvoegsel aan 'n spesifieke kliënt karteer. Daardie tabel word uit iroute-inskrywings gebou, daarom is 'n gewone roete op die bediener nie genoeg nie. Die kernel-roete kry die pakket by die tonnelkoppelvlak; die interne kartering besluit watter sessie dit ontvang. Dit is ook hoekom die herstelling nooit in die kernel se roete-uitset verskyn nie.

As die kartering ontbreek, kom die pakket by die bediener aan, pas by die tonnelroete en word laat vaar omdat geen kliënt die bestemming opeis nie. Niks teken 'n skoon fout aan nie, daarom lyk die fout soos 'n stil swart gat eerder as 'n roetelus.

Skryf die iroute-inskrywing wat die kliënt benoem

iroute woon in 'n kliëntspesifieke konfigurasielêer, nie in die hoofkonfigurasie van die bediener nie. Wys die bediener na 'n gids met die client-config-dir-opsie, skep dan 'n lêer wie se naam die kliënt se sertifikaat-common name is en plaas die voorvoegsel daarin.

Vir 'n tak waarvan die LAN 10.20.0.0/24 is en wie se sertifikaat-common name branch-router is, bevat die lêer by daardie pad 'n reël soos iroute 10.20.0.0 255.255.255.0. Die hoofkonfigurasie het net die gidsopsie nodig; die voorvoegsel woon by die kliënt.

Die common name is die brose deel. 'n Sertifikaat wat met 'n ander onderwerp uitgereik is, of 'n ontplooiing wat gebruikers by gebruikernaam verifieer terwyl die lêer na die sertifikaat vernoem is, lewer 'n lêer wat nooit gelees word nie. Kontroleer die naam wat die bediener werklik vir die sessie rapporteer, en oorweeg die opsie wat 'n onpaslike kliënt laat misluk eerder as om stilweg sonder sy roetes te koppel. Om die lêer te hernoem sodat dit by die sertifikaat pas, is 'n vyfminuut-regstelling wat 'n baie lang aand voorkom.

Een kliënt kan verskeie voorvoegsels besit. Voeg een iroute-reël per netwerk by en hou die lys langs die res van daardie kliënt se instellings sodat die kartering naspeurbaar bly.

Bou die terugpad in albei rigtings

Om pakkette na die afgeleë LAN te kry, is die helfte van die werk. Die kliënt moet ook daardie LAN se verkeer in die tonnel stuur, wat gewoonlik gedoen word deur 'n roete na die kliënt te stoot: 'n reël soos push "route 10.8.0.0 255.255.255.0" vertel elke kliënt hoe om die netwerk aan die bedienerkant te bereik. Vir die tak wys die ekwivalente roete na die tonnel vir alles wat dit aan die bedienerkant moet bereik.

Die terugrigting het 'n eienaar aan die oorkant nodig. Aan daardie kant moet iemand die pad terug ken: 'n statiese roete op die LAN-roeteerder wat die VPN-poel na die bediener wys, of adresvertaling op die bediener voordat verkeer die LAN binnegaan. Die statiese roete hou oorspronklike adresse sigbaar in logboeke en toegangsreëls, maar vereis die LAN-eienaar se samewerking; vertaling is selfstandig, maar verberg wie werklik gekoppel het.

Aanstuur moet op die bediener se gasheer geaktiveer wees. Sonder dit aanvaar die kernel die pakket van die tonnel en weier om dit na die LAN-koppelvlak deur te gee, wat van die kliënt se oogpunt af identies lyk aan 'n ontbrekende iroute.

Toets bereikbaarheid met die regte ondersoeke

Toets in lae in plaas daarvan om die verre kant te ping en te raai. Vanaf die bediener, kyk of die interne kartering vir die voorvoegsel bestaan en of die kernel-roete na die tonnel wys. Vanaf die kliënt, bevestig dat die gestootde roete geïnstalleer is en dat sy verstekpad vir die LAN-adres die tonnel is.

Kyk dan na pakkette. 'n Opname op die tonnelkoppelvlak wys of die bediener na die kliënt uitstuur, en 'n opname op die LAN-koppelvlak wys of dit aanstuur. As die eerste pakkette wys en die tweede niks nie, is aanstuur of 'n filter die probleem; as nie een iets wys nie, het die soektog vroeër gefaal.

Twee bedieners wat deur 'n tonnel verbind is, herhaal dieselfde reël aan albei kante: elkeen het 'n iroute vir die ander se poel nodig, en elkeen het die roete en aanstuur nodig wat die pad simmetries maak. Roetering en beleid is hier aparte kwessies. Roetering besluit waar 'n pakket kan gaan, terwyl 'n FORWARD-reël besluit of dit mag, so 'n kliënt met twee iroute-reëls kan albei voorvoegsels bereik tensy 'n filter anders sê.