Jedna NIC, nebo dvě? Jak rozhodnout o uspořádání rozhraní VPN serveru

Jeden fyzický adaptér stačí pro mnoho VPN serverů a také to není univerzální návrh. Šifrované spojení přichází na tento adaptér, proces VPN ho dešifruje a vnitřní provoz vychází přes virtuální rozhraní, než dorazí k místní službě nebo do směrované LAN. Zda to funguje, závisí na třech podmínkách: kde je cíl, zda má LAN zpětnou cestu k fondu klientů a zda vám jeden sdílený fyzický spoj dává izolaci, kterou tvrdíte. Odpovězte na tyto tři a počet adaptérů vyplyne sám.

Tři podmínky, které to rozhodují

První podmínkou je cíl. Ke službě na samotném hostiteli VPN se dostanete jen přes tunelové rozhraní, zatímco hostitel v LAN vyžaduje přeposílání a zpětnou cestu. Druhou podmínkou je tato zpětná cesta, protože zařízení v LAN musí vědět, jak dosáhnout fondu klientů, buď přes trasu, nebo překladem na serveru.

Třetí podmínkou je oddělení. Jeden adaptér znamená, že každý paket, šifrovaný nebo ne, sdílí jeden spoj a obvykle jeden řetězec zásad, takže tvrzení o izolaci, které závisí na samostatném hardwaru, jedno rozhraní nesplní. To je fakt o cestě, ne o tom, jak je nakonfigurovaný operační systém. Provoz tunelu můžete stále filtrovat, ale nemůžete tvrdit hranici, kterou nemáte.

Ani jedna ze tří se netýká počtu portů na šasi. Týkají se směrování, vlastnictví adres a toho, nakolik návrh závisí na fyzickém oddělení.

Dva adaptéry zůstávají legitimní volbou, když je ospravedlní fyzické zóny, samostatné uplinky, propustnost nebo mimosměrová cesta pro obnovu. To jsou konkrétní požadavky a stojí za to je vyslovit, než někdo objedná hardware.

Když služba běží na hostiteli VPN

Nejjednodušší případ nevyžaduje žádné přeposílání. Démon přijme pakety klienta na tunelovém rozhraní a předá je místnímu socketu a odpověď se vrací stejným rozhraním. Adresa fondu klientů je z pohledu hostitele skutečná místní adresa.

Dvě věci přesto musí být správně: služba musí naslouchat na adrese, kterou tunel dokáže dosáhnout, a firewall hostitele musí přijímat provoz přicházející na tunelové rozhraní. Obě jsou vidět v příkazech níže.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Navázání služby pouze na veřejnou adresu nebo omylem filtrované tunelové rozhraní vytvoří spojení, které dorazí k hostiteli a pak zemře. Vypadá to jako závada VPN a obvykle je to rozhodnutí socketu nebo firewallu.

Když cíl leží v LAN

Právě tady si návrh s jedním adaptérem vysloužil pověst náladového řešení. Server musí přeposílat pakety klienta směrem do LAN a zařízení v LAN musí posílat odpovědi zpět do fondu klientů. Buď tento fond nesete jako trasu v LAN, nebo překládáte zdrojovou adresu na serveru, aby se odpovědi vracely na samotný server.

Obě odpovědi jsou legitimní a selhávají různě. Zpětná trasa udržuje původní adresu klienta viditelnou pro cíl, což je dobré pro logy a špatné pro pravidla firewallu, která předpokládají adresy LAN. Překlad udržuje LAN jednoduchou a skrývá identitu klienta před cílem.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Asymetrická cesta je klasický příznak: požadavek klienta dorazí, odpověď odejde jiným routerem a spojení vyprší bez chyby na obou koncích. Zachyťte provoz na obou stranách, než o tunelu cokoli usoudíte.

Proč alias nevytváří druhou zónu

Přidání druhé adresy ke stejnému adaptéru nebo vytvoření fiktivního rozhraní, které má napodobit druhý port, mění jen velmi málo. Pakety stále odcházejí stejným fyzickým spojem, stejným portem přepínače a obvykle stejným řetězcem firewallu, takže mezi nimi nevzniká žádná nová hranice. Je to pohodlí konfigurace, ne segmentace. Považovat to za hranici zóny je způsob, jak tvrzení o izolaci přežije jen na papíře.

Samostatná zóna potřebuje skutečné oddělení v cestě, a to je požadavek, který splňuje druhý adaptér. Pokud pravidlo závisí na tom, že provoz směrem k VPN nikdy nesdílí broadcastovou doménu s provozem směrem k LAN, jeden kabel tuto vlastnost nedodá, ať je hostitel adresován jakkoli.

Kde produkt dokumentuje více-rozhraní topologii pro konkrétní režim, řiďte se dokumentací toho produktu, místo abyste vymýšleli obejití. Dodavatelé také mezi verzemi mění podporované topologie, což je další důvod číst aktuální příručku a ne starý snímek průvodce.

Ověřte uspořádání proti provozu, který povolujete

Vypište třídy provozu, které má server nést: klient k hostiteli, klient do LAN, hostitel do LAN a šifrované vnější spojení. Každá třída má zdroj, cíl a rozhraní a uspořádání musí splnit všechny čtyři najednou. Návrh, který zvládne tři z nich, je obvykle ten, který generuje tikety.

Potom potvrďte skutečná rozhraní a skutečný odchyt, ne diagram v návrhovém dokumentu. Příkazy níže vypíšou oba pohledy.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Pokud vnější odchyt ukazuje šifrovaný provoz a vnitřní odchyt ukazuje dešifrovaný provoz na tunelovém rozhraní, zatímco fyzický adaptér nese obojí, jedna NIC dělá svou práci. Pokud je vnitřní odchyt prázdný, problém je v tunelu nebo v pravidlech přeposílání, ne v počtu adaptérů. Rozhodněte topologii z těchto dvou odchytů a směrovací tabulky a další změna bude mít s čím se měřit.