Směrovaný nebo přemostěný VPN: vyberte podle toho, kam se klient musí dostat

Ve stejný den přijdou dva tikety: jeden uživatel potřebuje interní webovou aplikaci a jeden inženýr potřebuje, aby se stolní přístroj choval, jako by seděl ve stejném segmentu Ethernet. Na oba se odpovídá dejte je na VPN, a právě tam potíže začínají. Směrovaný tunel a přemostěný tunel vytvářejí různé vztahy a každému požadavku odpovídá jen jeden z nich. Volba topologie je rozhodnutí o přístupu, ne kryptografické nastavení.

Dva požadavky, které u přepážky vypadají stejně

Požadavkem zaměstnance je služba dosažitelná přes IP ze zařízení, které nekontrolujete. Požadavek inženýra je na úrovni spoje: přístroj očekává, že uvidí rámce Ethernet a broadcastové objevování, a možná i DHCP ze segmentu, ve kterém si myslí, že je.

To jsou různé otázky a odpověď mostem na obě bez důvodu rozšiřuje přístup zaměstnance na celou kancelářskou LAN.

Napište požadavek jako větu, než začnete vybírat: které cíle, které protokoly a kteří partneři mají vypadat lokálně. Pokud je odpovědí hostitel a port, směrování to pokryje. Pokud je odpovědí vztah na úrovni rámce se zařízeními, která mluví jen broadcastem, může být most jedinou možností. Vše mezi tím si zaslouží testovací segment místo produkční LAN.

Trasa je užší než členství v LAN

Směrovaný klient dostane adresu v tunelové podsíti a trasy pro prefixy, které zvolíte. Může dosáhnout aplikačního serveru a ničeho jiného, pokud to politika říká. Brána se stane místem prosazení, za předpokladu, že přes ni prochází každá relevantní cesta.

Nezaměňujte trasu s oprávněním. Říct klientovi, jak dosáhnout podsítě, mu nebrání zkusit jiný cíl.

Uplatněte řízení přístupu tam, kde skutečně může prosadit tok, a ponechte vlastní oprávnění aplikace na místě. Široké pravidlo předávání nebo zapomenuté druhé rozhraní mohou udělit víc, než naznačuje diagram. Čtěte platná pravidla, ne zamýšlená. Pak otestujte cíl, který má selhat, protože politika, kterou se nikdo nepokusil porušit, je hypotéza.

Most mění otázku přijetí

Přemostění spojuje fyzické rozhraní a zařízení TAP do softwarového přepínače, takže vzdálená zařízení se připojují ke stejné broadcastové doméně. To je skutečná schopnost a skutečné riziko: vzdálené zařízení už není směrovaný host, je to účastník.

Rozhodněte, která zařízení se smějí připojit, které typy rámců musí projít a kde se nežádoucí interakce blokuje. Adresování a autorita DHCP se stávají součástí sdílené sítě a dva servery DHCP v jednom segmentu vytvoří přesně ten zmatek, který očekáváte.

Pro přístroj obvykle lépe poslouží vyhrazený testovací segment než kancelářská LAN. Udržte správu mimo experiment a definujte, jak se dočasný účastník po skončení práce odstraní.

Filtrování existuje v obou topologiích

Most není sám o sobě nefiltrovatelný a trasa není sama o sobě bezpečná. Filtrování mostů v Linuxu má své háčky a vlastní syntaxi pravidel a pravidlo napsané pro směrované IP předávání se na přemostěné rámce automaticky nevztahuje.

Ověřte, co platforma skutečně podporuje, než nějakou hranici slíbíte:

bridge link show
nft list ruleset

TUN a TAP popisují provoz rozhraní, ne šifru. Přepnutí rozhraní nic z toho neopraví: autentizace partnerů, ukradený klíč i zastaralá kryptografická politika změnu přežijí. Obě strany stále potřebují nastavení, která si odpovídají a která jsou stále podporovaná.

Dokažte hranici třemi pokusy

Přijetí jsou tři pozorování, ne přehlídka diagramu. Požadovaná operace musí fungovat, nesouvisející cíl musí selhat a vlastní správní služby brány musí zůstat mimo dosah.

Spusťte povolenou i odmítnutou cestu ze stejného klienta a obě zaznamenejte:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

U mostu přidejte kontroly na úrovni spoje: zda prochází povolený provoz objevování, zda adresování pochází od zamýšlené autority a zda dočasný účastník po odstranění zmizel. Když prosté směrované IP požadavek už splňuje, připojení ke kancelářskému segmentu Ethernet potřebuje samostatné odůvodnění a to se má sepsat před změnou.