Oddaljeni uporabniki ne dosežejo druge lokacije skozi VPN zvezdišče

Oddaljeni uporabnik se poveže z zvezdiščem, doseže datotečni strežnik v njegovem lastnem LAN in vse se zdi zdravo. Nato odpre delež na 10.20.0.50 na sedežu, kamor zvezdišče doseže po ločenem tunelu lokacija-lokacija, in zahteva poteče. Oba tunela sta aktivna in oba števca naraščata, zato noben tunel ni pokvarjen. Prehod skozi zvezdišče so tri odločitve usmerjanja na treh napravah, in tunel prenaša le tiste predpone, za katere je bil zgrajen. Tu je vrstni red, po katerem preverjam, in ukaz, ki pokaže, ali vsak korak drži.

Tranzit zahteva tri iskanja, ne enega tunela

Vsaka naprava naredi svoje ujemanje najdaljše predpone in ga pozabi. Prenosnik mora poslati 10.20.0.50 v tunel, ne svojemu lokalnemu usmerjevalniku. Zvezdišče mora vzeti paket, ki je prispel na vmesnik oddaljenega dostopa, in ga izročiti vmesniku lokacija-lokacija. Sedež mora poslati odgovor na uporabnikov naslov nazaj skozi tunel. Katera koli od treh napak je v brskalniku videti enako: tišina.

Zato preverjanje vsakega tunela posebej dokaže tako malo. Pinganje naslova LAN zvezdišča preizkusi prvo odločitev, pinganje zvezdišča s sedeža pa tretjo. Paket, ki ne uspe, ima kot vir bazen uporabnikov in kot cilj drugo lokacijo, zato najprej zapišite ti predponi. Tu je bazen 10.80.0.0/24, LAN zvezdišča je 10.10.0.0/24, sedež pa 10.20.0.0/24.

Potisnite oddaljeno predpono do oddaljenega odjemalca

Na strežniku oddaljenega dostopa OpenVPN se odjemalec nauči poti ob povezavi. Brez push odjemalec z razdeljenim tunelom pošlje 10.20.0.50 svojemu prehodu in paket nikoli ne vstopi v tunel.

push "route 10.20.0.0 255.255.255.0"

Potisnjena pot začne veljati, ko se odjemalec poveže, zato uporabnik, ki ostane povezan, ne vidi ničesar, dokler se ne poveže znova. Preverite na odjemalcu: ip route get 10.20.0.50 v Linuxu, route print v Windows. Izpis naj bi navedel vmesnik tunela.

push zvezdišču ne pomaga. To je sporočilo odjemalcu, ne pot na strežniku in ne dovoljenje za posredovanje, zato zvezdišče s popolno vrstico push vseeno odvrže tok en skok naprej. To je običajen razlog, da ljudje sklenejo, da push ni uspel.

Dajte zvezdišču resnično izhodno pot

Zvezdišče potrebuje svoj naslednji skok za predpono sedeža. Na usmerjenem tunelu je to običajna pot skozi vmesnik lokacija-lokacija, in en ukaz pokaže tako izbrano pot kot izbrani vir:

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

Kjer je krak lokacija-lokacija sam OpenVPN, lahko pot živi v tej konfiguraciji z naslovom tunela partnerja kot prehodom: route 10.20.0.0 255.255.255.0 172.30.0.2. Prehod ni izbiren. Če ga izpustite, naslednji skok pade na privzeto vrednost izvedbe, ki se razlikuje med odjemalcem z eno oddaljeno točko in zvezdiščem z več partnerji.

IPsec, ki temelji na pravilnikih, je drugačen: jedro zvezdišča pošlje paket svojemu običajnemu prehodu LAN, pravilnik pa ga ujame na izhodu, zato pot tunela bodisi ne naredi ničesar bodisi vodi promet mimo pravilnika. Bodite pozorni na vir v zgornjem ukazu, ker 10.10.0.1 namesto naslova bazena pomeni, da je jedro izbralo naslov, ki ga bo oddaljena stran zavrnila. Tudi iroute ni odgovor; strežniku pove, kateri odjemalec ima podomrežje za svojim tunelom, ne pa kam pošiljati promet za tretjo lokacijo.

Razširite oddaljeno stran na bazen uporabnikov

Sedež že pokriva LAN zvezdišča, 10.10.0.0/24. Bazen uporabnikov je druga predpona in mora biti tudi v izbirnikih, sicer noben pravilnik ne pokrije odgovora, naslovljenega na 10.80.0.25. Vsak partner navede isti par nizov predpon s svoje strani:

# 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

local_ts ene naprave je remote_ts druge. Kopirajte blok zvezdišča na sedež in par se obrne, zato podrejeni SA nikoli ne vstane.

Starejša sintaksa ipsec.conf uporablja leftsubnet, ločen z vejicami. Delujoča varnostna povezava obdrži izbirnike, o katerih se je pogajala, zato po urejanju tunel znova vzpostavite. Izbirnik, spremenjen ob 10:00 in preizkušen proti SA, ki je vstal ob 09:40, še vedno ne uspe, čeprav je konfiguracijska datoteka ves čas videti pravilna.

Nato preverite zadnji skok. ip route get 10.80.0.25 na oddaljenem koncu naj bi kazal v tunel. Če storitev uporablja usmerjevalnik LAN kot privzeti prehod, tudi ta usmerjevalnik potrebuje povratno pot, sicer odgovor tam umre. Izvajanje tcpdump -ni eth1 host 10.80.0.25 na tem segmentu pokaže, ali je odgovor sploh zapustil končno točko.

Dovolite tok na zvezdišču

Posredovanje mora biti omogočeno in pot dovoljena. Omejite pravila na dve predponi, namesto da sprejmete vse med vmesniki.

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

Filtriranje povratne poti je tiha napaka ob tem: ko sta kraka na različnih vmesnikih, lahko rp_filter=1 zavrže odgovor, medtem ko se števec pravila za sprejem sploh ne premakne. Primerjajte iptables -vnL FORWARD pred poskusom in po njem. Pravilo, ki nikoli ne naraste, ni doseženo, zato poglejte plast nižje, namesto da bi ga prepisali.

Če tranzit potrebuje le ena skupina, postavite pot v datoteko za posameznega odjemalca pod client-config-dir, namesto da razširite globalni push. Source NAT na zvezdišču tudi odpravi potrebo po povratni poti na oddaljeni strani, vendar skrije uporabnikov naslov, zato dnevniki oddaljene lokacije in pravila na podlagi naslovov prenehajo razlikovati uporabnike.

Preverite z odjemalca, nato razveljavite v obratnem vrstnem redu

Preizkusite vrata TCP, ne le ICMP, ker ping lahko gre skozi, medtem ko storitev ostane blokirana. nc -vz 10.20.0.50 445 in traceroute -n 10.20.0.50 z odjemalca pokažeta, ali je drugi skok naslov tunela zvezdišča. Na zvezdišču tcpdump -ni tun0 host 10.20.0.50 in isti filter na vmesniku lokacija-lokacija: zahteva na obeh brez odgovora na katerem koli premakne težavo na oddaljeno stran.

Nato preizkusite nekaj, kar mora ostati blokirano. Če se odzove tudi gostitelj, do katerega se bazen ne bi smel nikoli prebiti, ste odprli več kot tranzit in pravila bi morali zožiti. Zvezdišče, ki posreduje vse v vsak krak, prestane prvi preizkus in pade na drugem.

Vodite seznam razveljavitve, ker so se spremenili štirje objekti in tri je lahko pozabiti: potisnjena pot, pot zvezdišča, izbirniki in pravila požarnega zidu. Razveljavite jih v obratnem vrstnem redu, znova vzpostavite SA in pustite enemu uporabniku, da se znova poveže. Delna razveljavitev pusti pot, ki kaže na tunel, ki se ne ujema več, in to je težje brati kot prvotna tišina. Priročnik OpenVPN 2.6 dokumentira push, route in iroute za vašo različico.