Vzdálení uživatelé se přes VPN hub nedostanou na druhou lokalitu

Vzdálený uživatel se připojí k hubu, dostane se na souborový server na vlastní LAN hubu a všechno vypadá zdravě. Pak otevře sdílenou složku na 10.20.0.50 v centrále, kam se hub dostává přes samostatný tunel mezi lokalitami, a vyprší to. Oba tunely běží a oba čítače rostou, takže žádný tunel není rozbitý. Průchod hubem jsou tři rozhodnutí o směrování na třech zařízeních a tunel nese jen prefixy, pro které byl postaven. Tohle je pořadí, které kontroluji, a příkaz, který ukáže, zda každý krok platí.

Přechod potřebuje tři pohledy, ne jeden tunel

Každé zařízení si dělá vlastní shodu nejdelšího prefixu a zapomene ji. Notebook musí poslat 10.20.0.50 do tunelu, a ne svému místnímu routeru. Hub musí vzít paket, který dorazil na rozhraní vzdáleného přístupu, a předat ho rozhraní mezi lokalitami. Centrála musí poslat odpověď na uživatelovu adresu zpět tunelem. Selhání kterékoli ze tří věcí vypadá v prohlížeči stejně: ticho.

Proto testování každého tunelu zvlášť dokazuje tak málo. Ping na LAN adresu hubu procvičí první rozhodnutí a ping na hub z centrály procvičí třetí. Paket, který selhává, má fond uživatelů jako zdroj a druhou lokalitu jako cíl, takže si ty prefixy nejdřív zapište. Tady je fond 10.80.0.0/24, LAN hubu 10.10.0.0/24 a centrála 10.20.0.0/24.

Pošlete vzdálený prefix vzdálenému klientovi

Na OpenVPN serveru vzdáleného přístupu se klient učí trasy při připojení. Bez push pošle klient s rozděleným tunelem 10.20.0.50 své bráně a paket se do tunelu nikdy nedostane.

push "route 10.20.0.0 255.255.255.0"

Pushnutá trasa se uplatní při připojení klienta, takže uživatel, který zůstane online, nevidí nic, dokud se znovu nepřipojí. Ověřte na klientovi: ip route get 10.20.0.50 na Linuxu, route print na Windows. Výstup má uvést rozhraní tunelu.

Push hubu nepomůže. Je to zpráva klientovi, ne trasa na serveru a ne povolení předávat, takže hub s dokonalým push řádkem tok stejně zahodí o skok dál. To je obvyklý důvod, proč lidé usoudí, že push selhal.

Dejte hubu skutečnou výstupní trasu

Hub potřebuje vlastní další skok pro prefix centrály. Na směrovaném tunelu je to obyčejná trasa přes rozhraní mezi lokalitami a jeden příkaz ukáže zvolenou trasu i zvolený zdroj:

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

Když je větev mezi lokalitami sama OpenVPN, může trasa žít v té konfiguraci s adresou tunelu protějšku jako bránou: route 10.20.0.0 255.255.255.0 172.30.0.2. Brána není volitelná. Vynechte ji a další skok padne na výchozí hodnotu implementace, která se liší mezi klientem s jediným protějškem a hubem s více protějšky.

IPsec založený na zásadách je jiný: jádro hubu pošle paket své běžné LAN bráně a zásada ho zachytí na cestě ven, takže trasa tunelu buď nedělá nic, nebo vede provoz mimo zásadu. Hlídejte zdroj v příkazu výše, protože 10.10.0.1 místo adresy fondu znamená, že jádro zvolilo adresu, kterou vzdálená strana odmítne. iroute také není odpověď; říká serveru, který klient vlastní podsíť za svým tunelem, ne kam posílat provoz pro třetí lokalitu.

Rozšiřte vzdálenou stranu na fond uživatelů

Centrála už pokrývá LAN hubu, 10.10.0.0/24. Fond uživatelů je druhý prefix a musí být také v selektorech, jinak žádná zásada nepokrývá odpověď adresovanou 10.80.0.25. Každý protějšek uvádí stejnou dvojici sad prefixů ze své strany:

# 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 jednoho zařízení je remote_ts druhého. Zkopírujte blok hubu do centrály a dvojice se obrátí, takže child SA nikdy nevznikne.

Starší ipsec.conf syntaxe používá čárkami oddělený leftsubnet. Běžící bezpečnostní asociace si ponechává selektory, které vyjednala, takže po úpravě tunel znovu navazte. Selektor změněný v 10:00 a testovaný proti SA, která vznikla v 09:40, stále selhává, zatímco konfigurační soubor po celou dobu vypadá správně.

Pak zkontrolujte poslední skok. ip route get 10.80.0.25 na vzdáleném koncovém bodu má ukazovat do tunelu. Pokud služba používá LAN router jako výchozí bránu, potřebuje i ten router zpáteční trasu, jinak tam odpověď umře. Spuštění tcpdump -ni eth1 host 10.80.0.25 na tom segmentu ukáže, zda odpověď koncový bod vůbec opustila.

Povolte tok na hubu

Předávání musí být zapnuté a cesta povolená. Omezte pravidla na dva prefixy místo přijímání všeho mezi rozhraními.

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

Filtrování zpětné cesty je tichá porucha vedle toho: když jsou obě větve na různých rozhraních, rp_filter=1 může odpověď zahodit, zatímco čítač pravidla pro přijetí se nikdy nehne. Porovnejte iptables -vnL FORWARD před pokusem a po něm. Pravidlo, které nikdy nepřibývá, není dosaženo, takže se podívejte o vrstvu níž, místo abyste ho přepisovali.

Pokud přechod potřebuje jen jedna skupina, dejte trasu do souboru pro klienta pod client-config-dir místo rozšiřování globálního push. Zdrojový NAT na hubu také odstraní potřebu zpáteční trasy na vzdálené straně, ale skryje uživatelovu adresu, takže logy vzdálené lokality a pravidla založená na adrese přestanou uživatele rozlišovat.

Ověřte z klienta a pak vraťte v opačném pořadí

Testujte TCP port, ne jen ICMP, protože ping projde, zatímco služba zůstává blokovaná. nc -vz 10.20.0.50 445 a traceroute -n 10.20.0.50 z klienta ukážou, zda je druhý skok adresa tunelu hubu. Na hubu tcpdump -ni tun0 host 10.20.0.50 a stejný filtr na rozhraní mezi lokalitami: požadavek na obou bez odpovědi na kterémkoli přesune problém na vzdálenou stranu.

Pak otestujte něco, co musí zůstat blokované. Pokud odpoví i hostitel, na který se fond nikdy nemá dostat, otevřeli jste víc než přechod a měli byste pravidla zúžit. Hub, který předává všechno každé větvi, projde prvním testem a selže ve druhém.

Veďte seznam pro vrácení, protože se změnily čtyři objekty a tři se snadno zapomenou: pushnutá trasa, trasa hubu, selektory a pravidla firewallu. Vraťte je v opačném pořadí, znovu navazte SA a nechte jednoho uživatele se znovu připojit. Částečné vrácení nechá trasu ukazující na tunel, který už neodpovídá, což se čte hůř než původní ticho. příručka OpenVPN 2.6 dokumentuje push, route a iroute pro vaši verzi.