VPN hosta na ESXi: směrování, nebo přemostění — rozhodněte před port group
Směrovaný TUN potřebuje zpětné trasy; přemostěný TAP potřebuje dosah druhé vrstvy a širší politiku port group. Určete roli dřív, než rozšíříte promiskuitní režim.
Směrujte pakety, nebo rozšiřte Ethernet doménu: změna port group přichází až po této volbě. Z pohledu aplikace s privátní adresou mohou výsledky vypadat stejně, zatímco požadavky na hypervisor nejsou vůbec podobné. Proto se port group rozšiřuje první a otázka návrhu se zodpovídá druhá, obvykle po broadcastové bouři. Projděte tyto kontroly v pořadí a zastavte se, dokud je požadavek stále nejasný, protože žádné nastavení port group nenapraví návrh, který nikdy nebyl zvolen.
Rozhodnutí patří vlastníkovi služby; konfigurace hypervisoru ho má provést, ne ho náhodou určit.
Zjistěte, co protější strana skutečně potřebuje
Vypište služby, ke kterým se vzdálení klienti musí dostat, a protokoly, které používají. Pokud je seznam hrstka TCP služeb na známých prefixech, směrování to pokryje. Pokud něco skutečně potřebuje sousedství 2. vrstvy — objevování závislé na broadcastu, ne-IP protokoly, zařízení, které nepřijme bránu — směrování to nedokáže napodobit a je třeba to říct včas. Buďte upřímní ohledně ne-IP položek v tom seznamu, protože právě tam směrovaný návrh po týdnu tiše selže.
Pak zkontrolujte klientský pool. Směrovaný návrh potřebuje rozsah adres a výslovnou zpětnou trasu na protější straně; přemostěný návrh potřebuje, aby rozšířená Ethernet doména vlastnila přidělování adres a izolaci. Ať zvolíte cokoli, někdo mimo tento VM s tím musí souhlasit.
Co každý návrh vyžaduje od virtuální sítě
Oba návrhy se liší v tom, co musí virtuální síť snést, a tabulka je nejkratší způsob, jak to vidět:
| Návrh | Role na straně hosta | Co musí virtuální síť pojmout | Režim selhání při špatné volbě |
|---|---|---|---|
| Směrovaný TUN | Router mezi oddělenými prefixy | Směrovaný klientský pool plus zpětné cesty na protější straně | Klienti dosáhnou brány a nikdy nedosáhnou služby za ní |
| Přemostěný TAP | Přemostění 2. vrstvy pro klienty, kteří se připojí | Další Ethernet identity, broadcastový provoz a pravidla VLAN | vSwitch zahazuje rámce, nebo návrh vyžaduje promiskuitní režim, který nikdo neschválil |
Směrování nechává broadcastovou doménu tam, kde je, a dává přirozené místo pro omezení, které služby procházejí bránou. Přemostění posouvá hranici: klienti se stávají účastníky rozšířené Ethernet domény a přidělování adres, izolace i jakákoli politika 2. vrstvy se nyní vztahují na ně. Zapište zvolený řádek do záznamu o změně. Věta jako „směrovaný TUN, klientský pool 10.90.0.0/24, zpětná trasa na jádru“ zabrání dalšímu inženýrovi znovu rozebírat návrh z nastavení port group.
Kdo smí vidět čí rámce
Položte vlastníkovi platformy jednu otázku, než se dotknete port group: vyžaduje návrh, aby tento VM přijímal rámce adresované jiným účastníkům? Pokud je odpověď ne, nic v této části se neuplatní, protože směrovaný TUN takovou viditelnost nikdy nepotřebuje. Pokud je odpověď ano, pokyny Broadcomu k promiskuitnímu režimu jsou to pravé čtení: vysvětlují, kolik víc z vSwitch VM vidí, a doporučují omezit tuto politiku na jednu port group.
Berte to jako kontrolu požadavku, ne jako povolení. Zapněte nastavení pro jedno vyhrazené připojení, když je potřeba přemostění zapsaná, a všude jinde ho nechte vypnuté. Široký VLAN trunk zkopírovaný z jiného příkladu přemostění je část, kterou nikdo nezapomene odstranit, a návrh s jedním VLAN má zůstat s jedním VLAN.
Zaznamenejte, která port group se změnila a proč, na stejné místo, kam jste zapsali řádek návrhu. Právě tato dvojice umožňuje příští audit.
Udržujte objekty hosta explicitní
Uvnitř Linuxu jsou členství v přemostění a vlastnictví adresy oddělené objekty a jejich slučování způsobuje matoucí polofunkční stav. Přidělujte adresy rozhraní přemostění nebo směrovanému tunelu, ne oběma stranám stejné cesty, a členské porty držte bez IP konfigurace.
Vyhněte se umístění jedné podsítě nezávisle na směrovaném TUN a na nesouvisejícím Ethernet rozhraní. Taková konfigurace vytváří dvě cesty ke stejnému prefixu, asymetrické odpovědi a vlákno podpory o flappingu, které nezmiňuje ani jednu cestu. Pokud host také hostuje kontejnery nebo lokální hypervisor, zkontrolujte, že už nepřemostují do stejného uplinku. Dva mosty na jedné NIC jsou návrh, ne nehoda, kterou chcete objevit během změnového okna.
Potvrďte cestou paketu, ne pingem
Ověřte skutečnou cestu, ne jen dosažitelnost. Z klienta potvrďte, která zdrojová adresa dorazí ke vzdálené službě, a pak že odpověď se vrací stejnou cestou. Na hostu zkontrolujte počítadla předávání pro konkrétní tok a na port group potvrďte, že není zapnutá žádná další viditelnost nad rámec zvoleného návrhu.
Nakonec otestujte směr selhání. Zastavte tunel nebo odpojte klienta a zkontrolujte, že provoz tiše nespadá na směrovanou cestu, kterou jste považovali za nevyužitou, protože právě tento pád je způsob, jak se přemostěný návrh tiše stane nechtěným routerem.