LAN-enkursigilo kaj VPN-kliento: du aparatoj, du enkursigaj tabeloj

Du aparatoj plusendas la pakon kaj ĉiu tenas sian propran tabelon. La LAN-enkursigilo scias, ke la fora prefikso apartenas al la VPN-kliento, kaj la VPN-kliento scias, kiel atingi tiun prefikson tra sia tunelo. Agordu nur la unuan tabelon kaj la pako alvenas al maŝino, kiu ne havas kongruan vojon, do ĝi denove eliras per la implicita. Tio estas la tuta fiasko, kaj de la LAN-flanko ĝi aspektas kiel enkursiga buklo, ĉar ĝi preskaŭ estas unu.

Desegnu la du saltojn antaŭ ol tuŝi vojon

Prenu ilustran aranĝon: LAN-gastigantoj sur 192.168.50.0/24, la ordinara enkursigilo ĉe 192.168.50.1, dediĉita kliento ĉe 192.168.50.15, kaj fora LAN ĉe 10.60.0.0/24 atingebla nur tra la tunelo, kiun tiu kliento tenas. Neniu el la du privataj gamoj koincidas kun la alia, kaj la tunelo havas sian propran adresplanon.

Ambaŭ privataj gamoj gravas, ĉar ili decidas, kiu aparato povas respondi. La fora flanko vidos la pakon alveni de la tunela adreso de la kliento, kaj ĝia respondo devas trovi revenan vojon al 192.168.50.0/24. Se nur la elira direkto estas agordita, la peto povas funkcii dum la respondo malaperas.

Paŝo 1: direktu la enkursigilon al la kliento, ne al la tunelo

Sur la LAN-enkursigilo, aldonu celan vojon kies sekva salto estas la LAN-adreso de la kliento:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Tiu rikordo diras „liveru ĝin al la maŝino, kiu povas tuneli“. Ĝi diras nenion pri tio, kiel la tunelo estas konstruita, kaj ĝi ne anstataŭas la propran vojon de la kliento. Sur administrata enkursigilo la ekvivalento loĝas en la paĝo de statikaj vojoj de la aparato; sur Linux-enkursigilo ĝi apartenas al la interfaca agordo, kiu posedas la LAN-on, ne al ŝelo, kiun vi fermos.

Kontrolu la respondon de la dua komando. Se ĝi raportas la klienton kiel gateway kaj la LAN-interfacon kiel device, la unua salto estas ĝusta kaj la cetera laboro estas sur la alia maŝino.

Paŝo 2: donu al la kliento propran vojon ĉe la tunela flanko

La kliento nun ricevas pakon por 10.60.0.0/24 kaj konsultas sian propran tabelon. Se ĝia tunela agordo instalis vojon por tiu prefikso, la pako daŭras ĉifrita. Se ne, la pako kongruas kun la ordinara implicita vojo kaj revenas al 192.168.50.1, kiu sendas ĝin denove al la kliento.

Rigardu antaŭ ol aldoni ion:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Mankanta prefiksa vojo en ĉiuj tabeloj estas la trovo, kiun vi serĉas. Aldonu ĝin tra la propra agordo de la tunelo, por ke la sekva rekonekto reinstalu ĝin; permana ip route add malaperas kun la sesio kaj igas la difekton reveni en la plej maloportuna momento. La sekva salto estas la tunela interfaco aŭ la adreso, kiun la VPN asignas kiel sia kunulo, laŭ la kliento, kaj la kunula adreso devus veni el la nuna profilo anstataŭ el malnova noto.

La buklo, kiam ĝi okazas, praktike ne estas senfina: la TTL falas ĉe ĉiu paso kaj la pako mortas kun mesaĝo pri superita tempo. Tial ripetata traceroute povas sugesti ciklon, dum kliento, kiu simple ne plusendas, silenteme faligas la saman pakon.

Paŝo 3: permesu plusendadon kaj elektu la revenan vojon

Ricevado kaj plusendado estas malsamaj permesoj. net.ipv4.ip_forward=1 sur la kliento permesas transiron je la kernnivelo, kaj fajromura regulo ankoraŭ devas permesi ĝin inter la LAN-interfaco kaj la tunelo. Regulo, kiu permesas aliron al la propra administra paĝo de la kliento, ne permesos transiron al la fora LAN, kaj la distingo facile mankas, kiam la sama gastiganto respondas al ping loknivele.

La fora flanko havas la spegulan problemon. Ĝi devas scii, ke 192.168.50.0/24 estas atingebla tra tiu ĉi aŭtentikigita kliento. Kun OpenVPN tio kutime signifas po-klientan vojon puŝitan de la servila agordo, aŭ klient-specifan dosieron sur la servilo, kiu deklaras la LAN-on malantaŭ la kliento. Sen tio, la fora LAN aŭ faligas la respondon aŭ sendas ĝin al sia propra implicita pordego, do al la interreto.

Fonta tradukado estas la alternativo, kiam la LAN-prefikso ne povas esti anoncita. Limigita masquerade-regulo sur la kliento reverkas la fonton al la tunela adreso, kaj respondoj tiam revenas nature. Ĝi ankaŭ kaŝas, kiu LAN-gastiganto faris la peton, kaj ĝi mem ne permesas al la fora flanko iniciati konektojn enen. Elektu tiun kompromison konscie anstataŭ aldoni tutan masquerade kaj malkovri la kromefikon poste.

Paŝo 4: fiksu ambaŭ decidojn, poste testu la realan vojon

Ĉiu vojo havas posedanton, kaj la posedanto estas la agordo, kiu regeneriĝas ĉe lanĉo aŭ ĉe rekonekto. Sur la enkursigilo tio povas esti statika voja rikordo; sur la kliento ĝi povas esti la VPN-profio, NetworkManager aŭ systemd-networkd. Kontrolu rekonektante la tunelon kaj restartigante la klienton, poste relegu la tabelon anstataŭ fidi la redakton.

Tenu sendifekta la implicitan vojon, kiu portas la eksteran konekton de la tunelo. Anstataŭigi ĝin por „simpligi“ la aranĝon rompas la ĉifritan vojon antaŭ ol ajna interna trafiko povas uzi ĝin, kaj la simptomo estas tunelo, kiu neniam reestabliĝas post la ŝanĝo.

Testu de ordinara LAN-gastiganto, ne de la kliento, ĉar peto originiĝinta sur la kliento neniam ekzercas la unuan salton de la enkursigilo. Prenu servon, kiu ekzistas nur sur la fora LAN, kaj konfirmu la respondan korpon, poste kontrolu la nombrilojn aŭ protokolojn de la kliento por vidi la transiron okazi. Interna traceroute, kiu montras privatajn saltojn, pruvas plusendadon, ne ĉifradon: la ekstera vojo estas aparta observo, kaj nur la propraj interfacaj nombriloj de la tunelo montras, kio eliris tra ĝi.