Publika prefikso tra OpenVPN: ripari la returnan vojon

Rigardu la tunelon ekfunkcii kaj la klienton pongi la alian flankon, kaj poste publika adreso, kiu apartenas malantaŭ la VPN, respondas de aliloke, aŭ tute ne. Tiu simptomo kutime havas nenion komunan kun la ĉifro aŭ la atestiloj. Prefikso enkursigita de la provizanto estas liverata kiel IP-vojo, kaj porti ĝin tra OpenVPN signifas reprodukti tiun vojon je du niveloj kaj konservi la fontadreson sur la returna vojo. Ponti la WAN ne necesas, kaj aldoni la adreson al interfaco ne kreas la supran vojon.

La prefikso unue devas esti enkursigita al vi

Demandu la provizanton kiel la bloko estas liverata. Prefikso enkursigita al la ĉefa adreso de via servilo estas alia afero ol adresoj, kiujn la provizanto atendas atingi rekte sur WAN-segmento. Nur la unua modelo funkcias kun la dezajno ĉi tie.

Se la provizanto enkursigas 198.51.100.64/28 al via enira servilo, pakaĵoj por tiu intervalo alvenas al la servilo kaj haltas tie, krom se vi plusendas ilin. Se la provizanto anstataŭe pontas la intervalon al via uplink, la servilo devas respondi ARP por ĝi, kio estas alia problemo.

Testu la liveran modelon antaŭ ol tuŝi OpenVPN: de ekstere, pongu adreson en la bloko kaj rigardu, kiun interfacon ĝi ricevas. Se nenio alvenas, neniu tunela agordo helpos. Se la adreso respondas rekte sur la WAN, la provizanto pontas anstataŭ enkursigi, kaj la dezajno sube ne aplikiĝas.

Du enkursigaj niveloj: kernvojo kaj iroute

OpenVPN bezonas la prefikson en du lokoj. La kerno devas scii, ke la prefikso apartenas al la tunela aparato, por ke plusenditaj pakaĵoj eniru OpenVPN anstataŭ la defaŭlta vojo. OpenVPN ankaŭ devas scii, kiu aŭtentikigita kliento posedas la prefikson, kaj tio estas la iroute-enskribo en la klient-specifa dosierujo.

La vojo ĉe la servila flanko aspektas tiel, kun la prefikso kaj masko kongruantaj kun la atribuo:

ip route add 198.51.100.64/28 dev tun0

La klient-specifa agordo atribuas posedon. Metu ĝin en la CCD-dosieron nomitan laŭ la komuna nomo de la klienta atestilo, kaj konfirmu, ke tiu dosierujo estas la sama, kiun la servilo efektive legas:

iroute 198.51.100.64 255.255.255.240

La dokumentaro de OpenVPN pri enkursigitaj retoj priskribas ambaŭ nivelojn kaj kial ili estas apartaj. Kernvojo sen iroute sendas pakaĵojn en la tunelon sen posedanto, kaj OpenVPN forĵetas ilin. iroute sen la kernvojo lasas pakaĵojn sur la defaŭlta vojo de la servilo. Ambaŭ eraroj aspektas kiel rompita tunelo de la klienta flanko.

Kie loĝas la serva adreso

La delegita prefikso ne estas la sama afero kiel la propraj adresoj de la tunelo. Numeru la ligilon el la privata spaco se vi volas, kaj metu la publikan servan adreson tie, kie la servo efektive funkcias.

Sur Linux-kliento, kiu finas la servon loke, unu gastiga adreso sufiĉas:

ip address add 198.51.100.70/32 dev lo

Se la prefikso estas enkursigita plu al VM-gastigo aŭ alia LAN, agordu anstataŭe tiun suban vojon kaj ĝian returnan vojon. Atribui ĉiun adreson en la bloko al la VPN-kliento ne necesas kaj kreas konfliktojn poste.

Konservu la publikan fonton sur la returna vojo

Respondo el la delegita prefikso devas eliri tra la tunelo kaj atingi la vojon de la provizanto. Se la fora gastigo sendas ĝin tra sia propra ISP, la fontadreso aspektas falsigita, kaj la provizanto aŭ la celo forĵetas ĝin. La solvo estas regulo bazita sur la fonto aŭ dediĉita enkursiga tabelo, ne pli larĝa NAT. Sen ĝi, la servo funkcias de la tunela partnero kaj malsukcesas de ĉie alie.

Ĉe la enira servilo, larĝa masquerade-regulo estas la kutima kaŭzanto. Ĝi reskribas la publikan fonton al la ĉefa adreso de la servilo, kaj la kliento neniam vidas la veran:

iptables -t nat -S POSTROUTING

Limigu NAT al la privataj VPN-klientoj, kiuj bezonas ĝin, kaj lasu la delegitan prefikson netradukita. Poste konfirmu, ke la servilo entute plusendas la prefikson, ĉar plusenda ĉeno kun defaŭlta malpermeso forĵetas ĝin silente.

Kontrolu ambaŭ direktojn antaŭ ol fidi ĝin

La kontrolo estas kvar observoj, ne unu. Konfirmu, ke la vojo de la provizanto alvenas, ke la kerno sendas la prefikson en la tunelon, ke OpenVPN atribuas ĝin al la ĝusta kliento, kaj ke la respondo revenas kun la publika fonto sendifekta. Ĉiu observo havas sian propran komandon, do malsukceso montras tavolon anstataŭ la tutan dezajnon. Rulu ilin en tiu ordo post ĉiu agorda ŝanĝo.

Demandu la kernon, kiun vojon prenas delegita adreso, kaj observu la tunelon dum peto funkcias:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrado de inversa vojo povas nuligi ĝustan vojon. Kontrolu la efektivan agordon sur la tunelo kaj sur la uplink, kaj memoru, ke strikta reĝimo malakceptas trafikon, kies fonto ne kongruas kun la interfaco, sur kiu ĝi alvenis:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Finfine, testu la malsukcesan kazon. Haltigu la tunelon kaj konfirmu, ke la publika prefikso ne likas el la ordinara uplink. Restarigi la VPN devus revenigi la servon sen vastigi, kiujn pordojn la gastigo elmetas.