Udaljeni korisnici ne mogu preko VPN čvorišta doći do druge lokacije

Udaljeni korisnik spoji se na čvorište, dohvati datotečni poslužitelj na LAN-u samog čvorišta i sve izgleda zdravo. Zatim otvori dijeljeni resurs na 10.20.0.50 u sjedištu, do kojeg čvorište dolazi preko zasebnog tunela između lokacija, i to istekne. Oba tunela rade i oba brojača rastu, pa nijedan tunel nije pokvaren. Prelazak preko čvorišta su tri odluke o usmjeravanju na tri uređaja, a tunel nosi samo prefikse za koje je izgrađen. Ovo je redoslijed koji provjeravam i naredba koja pokazuje je li svaki korak istinit.

Prolaz traži tri provjere, a ne jedan tunel

Svaki uređaj sam radi vlastito podudaranje najduljeg prefiksa i zaboravi ga. Prijenosno računalo mora poslati 10.20.0.50 u tunel, a ne svom lokalnom usmjerivaču. Čvorište mora uzeti paket koji je stigao na sučelje udaljenog pristupa i predati ga sučelju između lokacija. Sjedište mora poslati odgovor za korisnikovu adresu natrag kroz tunel. Bilo koja od te tri pogreške izgleda isto u pregledniku: tišina.

Zato testiranje svakog tunela zasebno tako malo dokazuje. Ping na LAN adresu čvorišta vježba prvu odluku, a ping na čvorište iz sjedišta vježba treću. Paket koji pada ima bazen korisnika kao izvor i drugu lokaciju kao odredište, pa prvo zapišite te prefikse. Ovdje je bazen 10.80.0.0/24, LAN čvorišta 10.10.0.0/24, a sjedište 10.20.0.0/24.

Pošaljite udaljeni prefiks udaljenom klijentu

Na OpenVPN poslužitelju udaljenog pristupa klijent uči rute u trenutku spajanja. Bez push naredbe, klijent s podijeljenim tunelom šalje 10.20.0.50 svom pristupniku i paket nikada ne uđe u tunel.

push "route 10.20.0.0 255.255.255.0"

Poslana ruta stupa na snagu kad se klijent spoji, pa korisnik koji ostane na mreži ne vidi ništa dok se ponovno ne spoji. Provjerite na klijentu: ip route get 10.20.0.50 na Linuxu, route print na Windowsima. Izlaz treba navesti sučelje tunela.

Push ne pomaže čvorištu. To je poruka klijentu, ne ruta na poslužitelju i ne dopuštenje za prosljeđivanje, pa čvorište s besprijekornom push linijom ipak odbacuje tok jedan skok kasnije. To je uobičajen razlog zašto ljudi zaključe da je push zakazao.

Dajte čvorištu stvarnu izlaznu rutu

Čvorištu treba vlastiti sljedeći skok za prefiks sjedišta. Na usmjerenom tunelu to je obična ruta kroz sučelje između lokacija, a jedna naredba pokazuje i odabranu rutu i odabrani izvor:

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

Kad je krak između lokacija i sam OpenVPN, ruta može živjeti u toj konfiguraciji s adresom tunela partnera kao pristupnikom: route 10.20.0.0 255.255.255.0 172.30.0.2. Pristupnik nije neobavezan. Izostavite ga i sljedeći skok pada na zadanu vrijednost implementacije, koja se razlikuje između klijenta s jednim partnerom i čvorišta s više partnera.

IPsec temeljen na politici je drukčiji: jezgra čvorišta šalje paket svom uobičajenom LAN pristupniku i politika ga uhvati na izlazu, pa ruta tunela ili ne radi ništa ili usmjerava promet mimo politike. Pazite na izvor u gornjoj naredbi, jer 10.10.0.1 umjesto adrese bazena znači da je jezgra odabrala adresu koju će udaljena strana odbiti. iroute također nije odgovor; on govori poslužitelju koji klijent posjeduje podmrežu iza svog tunela, a ne kamo poslati promet za treću lokaciju.

Proširite udaljenu stranu na bazen korisnika

Sjedište već pokriva LAN čvorišta, 10.10.0.0/24. Bazen korisnika drugi je prefiks i mora biti i u selektorima, inače nijedna politika ne pokriva odgovor upućen na 10.80.0.25. Svaki partner navodi isti par skupova prefiksa sa svoje strane:

# 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 jednog uređaja je remote_ts drugoga. Kopirajte blok čvorišta u sjedište i par je obrnut, pa se child SA nikada ne podigne.

Starija ipsec.conf sintaksa rabi zarezima odvojen leftsubnet. Aktivna sigurnosna asocijacija zadržava selektore koje je dogovorila, pa ponovno uspostavite tunel nakon izmjene. Selektor promijenjen u 10:00 i testiran prema SA-u koji je podignut u 09:40 i dalje pada, dok konfiguracijska datoteka cijelo vrijeme izgleda ispravno.

Zatim provjerite zadnji skok. ip route get 10.80.0.25 na udaljenoj krajnjoj točki treba pokazivati u tunel. Ako usluga koristi LAN usmjerivač kao zadani pristupnik, tom usmjerivaču treba i povratna ruta, inače odgovor umire ondje. Pokretanje tcpdump -ni eth1 host 10.80.0.25 na tom segmentu pokazuje je li odgovor uopće napustio krajnju točku.

Dopustite tok na čvorištu

Prosljeđivanje mora biti omogućeno i put dopušten. Ograničite pravila na dva prefiksa umjesto da prihvatite sve između sučelja.

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 povratnog puta tiha je pogreška uz to: kad su dva kraka na različitim sučeljima, rp_filter=1 može odbaciti odgovor dok se brojač pravila prihvaćanja nikada ne pomakne. Usporedite iptables -vnL FORWARD prije i poslije pokušaja. Pravilo koje se nikada ne povećava nije dosegnuto, pa pogledajte sloj niže umjesto da ga prepisujete.

Ako samo jedna skupina treba prolaz, stavite rutu u datoteku po klijentu pod client-config-dir umjesto da proširite globalni push. Izvorni NAT na čvorištu također uklanja potrebu za povratnom rutom na udaljenoj strani, ali skriva korisnikovu adresu, pa zapisi udaljene lokacije i pravila temeljena na adresi prestaju razlikovati korisnike.

Provjerite s klijenta, pa vratite obrnutim redoslijedom

Testirajte TCP port, ne samo ICMP, jer ping može proći dok usluga ostaje blokirana. nc -vz 10.20.0.50 445 i traceroute -n 10.20.0.50 s klijenta pokazuju je li drugi skok adresa tunela čvorišta. Na čvorištu, tcpdump -ni tun0 host 10.20.0.50 i isti filtar na sučelju između lokacija: zahtjev na obama bez odgovora na ijednom seli problem na udaljenu stranu.

Zatim testirajte nešto što mora ostati blokirano. Ako i računalo koje bazen nikada ne smije dosegnuti odgovori, otvorili ste više od prolaza i trebate suziti pravila. Čvorište koje prosljeđuje sve svakom kraku prolazi prvi test i pada drugi.

Vodite popis za vraćanje, jer promijenjena su četiri objekta i tri je lako zaboraviti: poslanu rutu, rutu čvorišta, selektore i pravila vatrozida. Poništite ih obrnutim redoslijedom, ponovno uspostavite SA i pustite jednog korisnika da se ponovno spoji. Djelomično vraćanje ostavlja rutu prema tunelu koji više ne odgovara, što je teže čitati od izvorne tišine. OpenVPN 2.6 priručnik dokumentira push, route i iroute za vašu verziju.