Spojení lokalit proti vzdálenému přístupu přes VPN: co které z nich propojuje

Obě řešení se nazývají VPN a řeší různé problémy. Tunel mezi lokalitami spojuje dvě brány, takže každý hostitel za nimi může dosáhnout povolených adres na druhé straně, aniž by cokoli instaloval. Tunel vzdáleného přístupu připojuje jednotlivá zařízení k síti, vždy jeden klient. Srovnání je důležité, protože většina chyb při nasazení vzniká tím, že se jedno řešení nakonfiguruje a očekává se chování druhého, a příznakem bývá obvykle vypršení času u služby, ke které tunel skutečně dosáhl.

Dvě řešení, dvě hranice

Ani jedno řešení nerozšiřuje broadcastovou doménu LAN. Zařízení na vzdálené straně se neobjevují v místním seznamu objevování a očekávat, že se objeví, je prvním předpokladem, kterého je třeba se vzdát. Privátní názvy DNS, které záměrně publikujete, jsou předvídatelnější než jakýkoli objevovací protokol a přežijí změnu dodavatele.

Vezměte 10.10.0.0/24 na jedné lokalitě a 10.20.0.0/24 na druhé. Brána A potřebuje trasu nebo selektor provozu, který posílá prefix 10.20.0.0/24 do tunelu, a brána B potřebuje zrcadlový obraz. Hostitelé na obou stranách pak používají běžné IP spojení a nikdy se nedozvědí, že tunel existuje. Tato neviditelnost je funkcí a právě proto poruchy vypadají jako běžné síťové chyby, nikoli jako chyby tunelu.

Řešení založené na politice a na trase nejsou stejný tunel

Při nasazení IPsec založeném na politice vyjednané selektory provozu přesně určují, které páry zdroje a cíle jsou chráněny. Pokud se za jednou bránou objeví nová podsíť a žádný selektor ji nepokrývá, tunel zůstane aktivní a nová podsíť se prostě nepřenáší. V řešení založeném na trase přebírá provoz rozhraní a rozhoduje směrovací tabulka, což znamená, že přidání prefixu je změnou směrování, nikoli opětovným vyjednáním tunelu.

StrongSwan ukazuje oba pohledy přímo a jejich společné čtení je způsob, jak zjistit, který model jste vlastně nasadili.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Seznam selektorů, ve kterém chybí prefix, na kterém vám záleží, vysvětluje poruchu bez jakéhokoli zachytávání paketů, a trasa ukazující na špatné rozhraní vysvětluje zrcadlovou poruchu na zpáteční cestě. Přečtěte si obojí, než začnete cokoli znovu vyjednávat, protože obnovení klíče nepřidá selektor, který jste nikdy nenakonfigurovali.

Naplánujte adresování ještě před tunelem

Překrývající se rozsahy jsou chybou návrhu, kterou konfigurace neopraví. Pokud obě lokality používají 192.168.1.0/24, hostitel, který potřebuje 192.168.1.50, má dva kandidáty a žádný způsob, jak vybrat. Tunel se ověří, bezpečnostní asociace se navážou a směrovací rozhodnutí bude přesto špatné nebo nejednoznačné.

Vyberte jednu ze tří poctivých možností: přečíslujte jednu lokalitu, přeložte překrývající se rozsah na bráně, aby každá strana viděla jiný prefix, nebo se vzdejte přímého směrování pro tyto hostitele a publikujte službu jinak. Každá má svou cenu a první je obvykle nejlevnější v dvouletém horizontu. Rozhodněte se dřív, než tunel vznikne, protože dodatečná změna se dotkne každého zařízení se starou adresou.

Otázku MTU vyřešte také brzy. Tunel snižuje použitelnou zátěž a návrh spoléhající na fragmentaci se chová jinak než ten, který na branách stanoví MSS.

Předávání a politika stojí mimo tunel

Brána musí být ochotna předávat pakety mezi rozhraním tunelu a rozhraním LAN a oba směry potřebují politiku, která službu povoluje. V Linuxu jde o dvě samostatné volby, plus pravidla firewallu, která rozhodují, zda je předávaný tok vůbec povolen.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Přijímající hostitel přidává třetí vrstvu: jeho vlastní firewall musí stále přijmout klienta ze vzdálené podsítě. Souborový server, který povoluje jen svou místní /24, odmítne předávaný provoz z 10.20.0.7, ať tunel vypadá jakkoli zdravě, a toto odmítnutí se snadno přečte jako porucha směrování.

Testujte z hostitele, ne z brány

Ping vyslaný samotnou branou může sledovat jinou zdrojovou adresu a jinou politiku než předávaný provoz uživatelů. To z něj dělá slabý test a občas i zavádějící: uspěje, když aplikace selhává, nebo selže, když aplikace funguje.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Použijte skutečného hostitele, skutečnou zdrojovou adresu a skutečný protokol, který aplikace používá. Potom si přečtěte zpětnou cestu zvlášť, protože funkční dopředný směr bez zpětné trasy dává vypršení času, které vypadá stejně jako blokovaná služba.

Vyberte řešení podle otázky, na kterou odpovídáte: spojujete sítě, nebo přijímáte zařízení? Vše ostatní, včetně toho, kterého dodavatele konfigurujete, z toho vyplývá.