Foraj uzantoj ne atingas la duan ejon tra la VPN-hub

Transito tra la hubo bezonas tri serĉojn: la klientan itineron, la eliran itineron de la hubo kaj la revenan vojon de la malproksima flanko, plus unu limigitan plusendan regulon.

Fora uzanto konektiĝas al la hubo, atingas la dosier-servilon en la propra LAN de la hubo, kaj ĉio ŝajnas sana. Poste li malfermas kunhavaĵon ĉe 10.20.0.50 en la ĉefsidejo, kiun la hubo atingas per aparta ejo-al-eja tunelo, kaj ĝi tempolimas. Ambaŭ tuneloj estas aktivaj kaj ambaŭ nombriloj supreniras, do neniu tunelo estas difektita. Transiri la hubon estas tri enkursigaj decidoj sur tri aparatoj, kaj tunelo portas nur la prefiksojn por kiuj ĝi estis konstruita. Jen la ordo, kiun mi kontrolas, kaj la komando, kiu montras ĉu ĉiu paŝo veras.

Transito bezonas tri serĉojn, ne unu tunelon

Ĉiu aparato faras sian propran plejlongan-prefiksan kongruon kaj forgesas ĝin. La tekkomputilo devas sendi 10.20.0.50 en la tunelon anstataŭ al sia loka enkursigilo. La hubo devas preni paketon, kiu alvenis sur la fora-alira interfaco, kaj transdoni ĝin al la ejo-al-eja interfaco. La ĉefsidejo devas sendi respondon por la adreso de la uzanto reen tra la tunelo. Se unu el la tri malsukcesas, ĝi aspektas same en la retumilo: silento.

Tial testi ĉiun tunelon sola pruvas tiel malmulte. Pingi la LAN-adreson de la hubo ekzercas la unuan decidon, kaj pingi la hubon el la ĉefsidejo ekzercas la trian. La paketo, kiu malsukcesas, havas la uzantan basenon kiel fonton kaj la duan ejon kiel celon, do skribu tiujn prefiksojn unue. Ĉi tie la baseno estas 10.80.0.0/24, la LAN de la hubo estas 10.10.0.0/24 kaj la ĉefsidejo estas 10.20.0.0/24.

Puŝu la foran prefikson al la fora kliento

Sur OpenVPN fora-alira servilo la kliento lernas itinerojn ĉe konektiĝo. Sen push, kliento kun dividita tunelo sendas 10.20.0.50 al sia propra kluzo kaj la paketo neniam eniras la tunelon.

push "route 10.20.0.0 255.255.255.0"

Puŝita itinero ekvalidas kiam la kliento konektiĝas, do uzanto, kiu restas enrete, vidas nenion ĝis li rekonektiĝas. Kontrolu ĉe la kliento: ip route get 10.20.0.50 en Linux, route print en Windows. La eligo devus nomi la tunelan interfacon.

La push ne helpas la hubon. Ĝi estas mesaĝo al la kliento, ne itinero sur la servilo kaj ne permeso plusendi, do hubo kun perfekta push-linio ankoraŭ faligas la fluon unu salton poste. Tio estas la kutima kialo, kial homoj konkludas, ke la push malsukcesis.

Donu al la hubo veran eliran itineron

La hubo bezonas sian propran sekvan salton por la prefikso de la ĉefsidejo. Sur enkursigita tunelo tio estas ordinara itinero tra la ejo-al-eja interfaco, kaj unu komando montras kaj la elektitan itineron kaj la elektitan fonton:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Kiam la ejo-al-eja kruro mem estas OpenVPN, la itinero povas vivi en tiu agordo kun la tunela adreso de la partnero kiel kluzo: route 10.20.0.0 255.255.255.0 172.30.0.2. La kluzo ne estas laŭvola. Forlasu ĝin kaj la sekva salto falas al aplikaĵa defaŭlto, kiu malsamas inter unu-partnera kliento kaj plur-partnera hubo.

Politiko-bazita IPsec estas alia: la kerno de la hubo sendas la paketon al sia normala LAN-kluzo kaj la politiko kaptas ĝin survoje eksteren, do tunela itinero aŭ faras nenion aŭ direktas trafikon preter la politiko. Atentu la fonton en la supra komando, ĉar 10.10.0.1 anstataŭ la basena adreso signifas, ke la kerno elektis adreson, kiun la fora flanko rifuzos. iroute ankaŭ ne estas la respondo; ĝi diras al la servilo, kiu kliento posedas subreton malantaŭ sia propra tunelo, ne kien sendi trafikon por tria ejo.

Etendu la foran flankon al la uzanta baseno

La ĉefsidejo jam kovras la LAN de la hubo, 10.10.0.0/24. La uzanta baseno estas dua prefikso kaj devas esti ankaŭ en la selektiloj, alie neniu politiko kovras respondon adresitan al 10.80.0.25. Ĉiu partnero nomas la saman paron de prefiksaj aroj de sia flanko:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24
# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

La local_ts de unu aparato estas la remote_ts de la alia. Kopiu la huban blokon al la ĉefsidejo kaj la paro inversiĝas, do la child SA neniam ekas.

La pli malnova ipsec.conf sintakso uzas leftsubnet apartigitan per komoj. La kuranta sekureca asocio konservas la selektilojn, kiujn ĝi interkonsentis, do restarigu la tunelon post la redakto. Selektilo ŝanĝita je 10:00 kaj testita kontraŭ SA komenciĝinta je 09:40 ankoraŭ malsukcesas, dum la agorda dosiero aspektas ĝusta la tutan tempon.

Poste kontrolu la lastan salton. ip route get 10.80.0.25 sur la fora finpunkto devus montri en la tunelon. Se la servo uzas LAN-enkursigilon kiel defaŭltan kluzon, tiu enkursigilo ankaŭ bezonas la revenan itineron, alie la respondo mortas tie. Ruli tcpdump -ni eth1 host 10.80.0.25 sur tiu segmento montras, ĉu la respondo entute forlasis la finpunkton.

Permesu la fluon ĉe la hubo

Plusendo devas esti ŝaltita kaj la vojo permesita. Limigu la regulojn al la du prefiksoj anstataŭ akcepti ĉion inter la interfacoj.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Filtrado de revena vojo estas la silenta fiasko apude: kiam la du kruroj estas sur malsamaj interfacoj, rp_filter=1 povas faligi la respondon dum la nombrilo de la akcepta regulo neniam moviĝas. Komparu iptables -vnL FORWARD antaŭ kaj post provo. Regulo, kiu neniam pliiĝas, ne estas atingata, do rigardu tavolon pli malsupre anstataŭ reverki ĝin.

Se nur unu grupo bezonas transiton, metu la itineron en dosieron por kliento sub client-config-dir anstataŭ larĝigi la tutmondan push. Fonta NAT sur la hubo ankaŭ forigas la bezonon de fora revena itinero, sed ĝi kaŝas la adreson de la uzanto, do la protokoloj de la fora ejo kaj adres-bazitaj reguloj ĉesas distingi uzantojn.

Kontrolu de la kliento, poste restarigu laŭ inversa ordo

Testu TCP-pordon, ne nur ICMP, ĉar ping povas pasi dum la servo restas blokita. nc -vz 10.20.0.50 445 kaj traceroute -n 10.20.0.50 de la kliento montras, ĉu la dua salto estas la tunela adreso de la hubo. Sur la hubo, tcpdump -ni tun0 host 10.20.0.50 kaj la sama filtrilo sur la ejo-al-eja interfaco: peto sur ambaŭ sen respondo sur iu ajn movas la problemon al la fora flanko.

Poste testu ion, kio devas resti blokita. Se ankaŭ gastiganto, kiun la baseno neniam rajtas atingi, respondas, vi malfermis pli ol transiton kaj devus mallarĝigi la regulojn. Hubo, kiu plusendas ĉion al ĉiu branĉo, pasas la unuan teston kaj malsukcesas la duan.

Tenu liston por restarigo, ĉar kvar objektoj ŝanĝiĝis kaj tri facile forgeseblas: la puŝita itinero, la itinero de la hubo, la selektiloj kaj la fajroŝirmaj reguloj. Malfaru ilin laŭ inversa ordo, restarigu la SA, kaj lasu unu uzanton rekonektiĝi. Parta restarigo lasas itineron montrantan al tunelo, kiu jam ne kongruas, kio estas pli malfacile legebla ol la origina silento. La manlibro de OpenVPN 2.6 dokumentas push, route kaj iroute por via versio.

Rilataj artikoloj