Kial la subreto malantaŭ OpenVPN-kliento estas neatingebla?

Pingoj al la tunela adreso de la servilo sukcesas, la propra vojregulo de la kliento aspektas ĝusta, kaj la LAN malantaŭ tiu kliento restas neatingebla. La vojregulo de la kliento aspektas korekta, la servilo havas vojon al la tunelo, kaj pakaĵoj daŭre malaperas. Ĝi estas la klasika simptomo de layer-3-tunelo, kiu ne scias, ke unu el ĝiaj klientoj estas ankaŭ pordego.

tun-interfaco ne havas sekvan saltan punkton por ĉiu kliento. La kerno vidas unu interfacon kun multaj samtavolanoj, do la decido, kiu kliento ricevu pakaĵon por malproksima LAN, devas esti farita ene de la OpenVPN-procezo. Tiu decido estas agordata per iroute, kaj sen ĝi la pakaĵo ne havas kien iri.

La servilo vojigas laŭ kliento, ne laŭ interfaco

Kiam la servilo devas sendi pakaĵon al la tunela adreso de kliento, la respondo estas senduba: la adreso apartenas al la sesio de tiu kliento. Kiam la celo estas tuta subreto malantaŭ tiu kliento, la adreso apartenas al neniu, kiun la servilo konas, kaj la kernovojo al la tunelo nur diras "tra ĉi tiu interfaco" sen diri, kiu samtavolano.

OpenVPN solvas tion per interna vojregulo, kiu mapas celan prefikson al specifa kliento. Tiu tabelo estas konstruata el iroute-enskriboj, tial ordinara vojo sur la servila gastiganto ne sufiĉas. La kernovojo kondukas la pakaĵon al la tunela interfaco; la interna mapado decidas, kiu sesio ricevas ĝin. Tial ankaŭ la riparo neniam aperas en la vojeligilo de la kerno.

Se la mapado mankas, la pakaĵo alvenas al la servilo, kongruas kun la tunelvojo kaj estas forĵetata, ĉar neniu kliento postulas la celon. Nenio registras puran eraron, tial la paneo aspektas kiel silenta nigra truo anstataŭ vojiga buklo.

Verki la iroute-enskribon, kiu nomas la klienton

iroute loĝas en klient-specifa agordodosiero, ne en la ĉefa agordo de la servilo. Direktu la servilon al dosierujo per la opcio client-config-dir, poste kreu dosieron, kies nomo estas la komuna nomo de la atestilo de la kliento, kaj metu la prefikson en ĝin.

Por filio, kies LAN estas 10.20.0.0/24 kaj kies atestila komuna nomo estas branch-router, la dosiero sur tiu vojo enhavas linion kiel iroute 10.20.0.0 255.255.255.0. La ĉefa agordo bezonas nur la dosierujan opcion; la prefikso loĝas ĉe la kliento.

La komuna nomo estas la rompiĝema parto. Atestilo eldonita kun alia subject, aŭ instalado, kiu aŭtentigas uzantojn per uzantnomo dum la dosiero estas nomita laŭ la atestilo, produktas dosieron, kiu neniam estas legata. Kontrolu la nomon, kiun la servilo efektive raportas por la sesio, kaj konsideru la opcion, kiu igas neakordan klienton malsukcesi anstataŭ silente konektiĝi sen siaj vojoj. Renomi la dosieron por kongrui kun la atestilo estas kvinminuta ripareto, kiu malhelpas tre longan vesperon.

Unu kliento povas posedi plurajn prefiksojn. Aldonu unu iroute-linion por ĉiu reto, kaj tenu la liston apud la ceteraj agordoj de tiu kliento, por ke la mapado restu revidebla.

Konstrui la revenan vojon en ambaŭ direktoj

Venigi pakaĵojn al la malproksima LAN estas duono de la laboro. La kliento ankaŭ devas sendi la trafikon de tiu LAN en la tunelon, kio kutime okazas per puŝo de vojo al la kliento: linio kiel push "route 10.8.0.0 255.255.255.0" diras al ĉiu kliento, kiel atingi la reton ĉe la servila flanko. Por la filio, la ekvivalenta vojo montras al la tunelo por ĉio, kion ĝi devas atingi ĉe la servila flanko.

La revena direkto bezonas posedanton ĉe la malproksima flanko. Tie iu devas scii la vojon reen: statika vojo sur la LAN-vojigilo, kiu direktas la VPN-baseno al la servilo, aŭ adresa traduko sur la servilo antaŭ ol la trafiko eniras la LAN. La statika vojo konservas la originajn adresojn videblaj en protokoloj kaj alirreguloj, sed postulas la kunlaboron de la LAN-posedanto; traduko estas memstara sed kaŝas, kiu efektive konektiĝis.

Plusendado devas esti ŝaltita sur la servila gastiganto. Sen ĝi la kerno akceptas la pakaĵon el la tunelo kaj rifuzas pasigi ĝin al la LAN-interfaco, kio el la vidpunkto de la kliento aspektas idente al mankanta iroute.

Kontroli atingeblon per la ĝustaj sondoj

Testu laŭ tavoloj anstataŭ pingi la malproksiman finon kaj diveni. De la servilo, kontrolu, ke la interna mapado por la prefikso ekzistas kaj ke la kernovojo montras al la tunelo. De la kliento, konfirmu, ke la puŝita vojo estas instalita kaj ke ĝia defaŭlta vojo por la LAN-adreso estas la tunelo.

Poste observu la pakaĵojn. Kaptaĵo sur la tunela interfaco montras, ĉu la servilo elsendas al la kliento, kaj kaptaĵo sur la LAN-interfaco montras, ĉu ĝi plusendas. Se la unua montras pakaĵojn kaj la dua nenion, la problemo estas plusendado aŭ filtrilo; se neniu montras ion, la serĉo malsukcesis pli frue.

Du serviloj kunligitaj per tunelo ripetas la saman regulon ambaŭflanke: ĉiu bezonas iroute por la baseno de la alia, kaj ĉiu bezonas la vojon kaj plusendadon, kiuj faras la vojon simetria. Vojigado kaj politiko estas apartaj aferoj ĉi tie. Vojigado decidas, kien pakaĵo povas iri, dum regulo FORWARD decidas, ĉu ĝi rajtas, do kliento kun du iroute-linioj povas atingi ambaŭ prefiksojn, se filtrilo ne diras alie.