Několik klientů TAP nevyžaduje jeden proces serveru, jeden port UDP a jedno zařízení TAP na hostiteli pro každého. Jeden server OpenVPN v režimu Ethernet může přijmout mnoho ověřených klientů a připojit je k jedinému mostu, a to je dokumentovaný způsob rozšíření segmentu vrstvy 2. Návrh s jediným procesem je ten, který dokumentuje příručka, a obvykle je správným výchozím nastavením.

Skutečnou otázkou je, zda mají tito klienti tento segment sdílet. Počet procesů na to neodpovídá, protože vlastnosti izolace vycházejí z topologie, nikoli z toho, kolik démonů běží. Zbytek tohoto srovnání je o obou topologiích a o tom, co každá usnadňuje.

Dvě architektury, ne dvě nastavení

Směrované nasazení TUN dává každému klientovi spojení bod-bod do směrovací domény serveru. Vysílání se zastaví na serveru, klienti nevidí rámce toho druhého a provoz mezi klienty, pokud existuje, musí být výslovně směrován a filtrován.

Přemostěné nasazení TAP činí klienty členy jednoho segmentu Ethernet. Vidí vysílání, mohou se navzájem rozlišit pomocí ARP a k oddělení spoléhají na politiku mostu a firewallu, nikoli na směrování. To je užitečné, když se klienti musí jevit, jako by byli zapojeni do stejného přepínače.

Srovnání je tedy o tom, čeho musí klienti dosáhnout, ne o výkonu. Nejprve zvolte vrstvu, potom rozhodněte, kolik procesů ji obsluhuje.

Co dělá pomocník server-bridge

Pomocník server-bridge konfiguruje režim Ethernet pro více klientů. Jeho forma s fondem adres přebírá bránu, masku sítě a vyhrazený rozsah uvnitř přemostěné podsítě, například bránu 192.168.50.1 s fondem od 192.168.50.160 do 192.168.50.199.

Vyhraďte tento rozsah mimo jakékoli jiné přidělování DHCP nebo statické přiřazení. Pomocník z něj přiděluje adresy, ale nekoordinuje se s jiným přidělovačem ve stejném segmentu a dva překrývající se fondy vytvářejí duplicitní adresy, které vypadají jako náhodné výpadky konektivity. Zapište vyhrazený rozsah do adresního plánu lokality, aby jej další člověk znovu nepoužil. Komentář v konfiguraci serveru je špatnou náhradou takového záznamu.

Pro nasazení, kde adresy přiděluje externí server, existuje forma s proxy DHCP. Má své vlastní předpoklady a mísení obou forem vytváří přesně ten konflikt, před kterým dokumentace varuje. Zvolte jeden přidělovač pro přemostěnou podsíť.

Izolace nevychází z počtu procesů

Osm procesů OpenVPN připojených ke stejnému neomezenému mostu stále sdílí jednu doménu vysílání. Klienti mohou přes most posílat ARP jeden druhému a počet posluchačů na tom nic nezměnil.

Pokud je požadavkem, aby skupiny klientů na vrstvě 2 neviděly jedna druhou, potřebuje návrh oddělené mosty nebo připojení VLAN spolu s přístupovými pravidly, která k nim patří. To je rozhodnutí o návrhu sítě a je stejné, ať už se týká jednoho procesu serveru, nebo osmi. Filtrování mostu může omezit část provozu, ale nevytváří oddělené domény vysílání. Berte je jako doplněk segmentace, ne jako její náhradu.

Pokud je požadavkem jen to, aby se klienti dostali k určitým službám IP, bývá směrovaný návrh TUN jednodušší než přemostění s filtrováním. Každý klient dostane své vlastní spojení a politika žije v pravidlech směrování a firewallu místo ve vnitřnostech mostu.

Kdy je několik procesů stále správné

Oddělené procesy lze odůvodnit provozními potřebami: různá autentizační rozhraní, různé certifikační autority, oddělené cykly aktualizace nebo nekompatibilní sady voleb. To jsou skutečné důvody a jsou nezávislé na počtu klientů.

Používáte-li jich několik, dejte každému vlastní naslouchač a vlastnictví zařízení a sladťte rozsahy adres. Dva servery, které oba věří, že vlastní stejný fond na stejném mostu, nakonec přidělí stejnou adresu.

Poté návrh ověřte s několika klienty najednou. Zkontrolujte, že adresy jsou jedinečné, že zamýšlený provoz mezi klienty funguje a že dvojice, která komunikovat nesmí, to nedokáže. Úspěšný ping jednoho klienta neprověří nic z návrhu pro více klientů.

Přečtěte si most a režim serveru z běžícího hostitele, než uvěříte diagramu. Konfigurace, na které záleží, je ta, kterou jádro a démon skutečně načetly, a právě tu může recenzent ověřit.

Související články