VPN hosťa na ESXi: smerovanie alebo most — rozhodnite pred port group
Smerovaný TUN potrebuje spätné trasy; mostovaný TAP potrebuje dosah druhej vrstvy a širšiu politiku port group. Určte rolu skôr, než rozšírite promiskuitný režim.
Smerujte pakety alebo rozšírte doménu Ethernet: zmena port group prichádza až po tejto voľbe. Z pohľadu aplikácie s privátnou adresou môžu výsledky vyzerať rovnako, kým požiadavky hypervisora nie sú vôbec podobné. Preto sa port group rozširuje prvá a otázka návrhu sa zodpovedá druhá, zvyčajne po broadcastovej búrke. Prejdite tieto kontroly v poradí a zastavte, kým je požiadavka ešte nejasná, pretože žiadne nastavenie port group nenapraví návrh, ktorý nebol nikdy zvolený.
Rozhodnutie patrí vlastníkovi služby; konfigurácia hypervisora ho má vykonať, nie ho náhodou určiť.
Zistite, čo protistrana skutočne potrebuje
Vypíšte služby, ku ktorým sa vzdialení klienti musia dostať, a protokoly, ktoré používajú. Ak je zoznam hŕstka TCP služieb na známych prefixoch, smerovanie to pokryje. Ak niečo naozaj potrebuje susedstvo 2. vrstvy — objavovanie závislé od broadcastu, ne-IP protokoly, zariadenie, ktoré neprijme bránu — smerovanie to nedokáže napodobniť a treba to povedať skoro. Buďte úprimní ohľadom ne-IP položiek v tom zozname, pretože práve tam smerovaný návrh po týždni ticho zlyhá.
Potom skontrolujte klientsky pool. Smerovaný návrh potrebuje rozsah adries a výslovnú spätnú trasu na protistrane; mostovaný návrh potrebuje, aby rozšírená doména Ethernet vlastnila prideľovanie adries a izoláciu. Čokoľvek si vyberiete, niekto mimo tohto VM s tým musí súhlasiť.
Čo každý návrh vyžaduje od virtuálnej siete
Oba návrhy sa líšia v tom, čo musí virtuálna sieť zniesť, a tabuľka je najkratší spôsob, ako to vidieť:
| Návrh | Rola na strane hosťa | Čo musí virtuálna sieť pojať | Režim zlyhania pri nesprávnej voľbe |
|---|---|---|---|
| Smerovaný TUN | Smerovač medzi oddelenými prefixmi | Smerovaný klientsky pool plus spätné cesty na protistrane | Klienti dosiahnu bránu a nikdy nedosiahnu službu za ňou |
| Mostovaný TAP | Most 2. vrstvy pre klientov, ktorí sa pripoja | Ďalšie Ethernet identity, broadcastová prevádzka a pravidlá VLAN | vSwitch zahadzuje rámce, alebo návrh vyžaduje promiskuitný režim, ktorý nikto neschválil |
Smerovanie necháva broadcastovú doménu tam, kde je, a dáva prirodzené miesto na obmedzenie, ktoré služby prechádzajú bránou. Mostovanie posúva hranicu: klienti sa stávajú účastníkmi rozšírenej domény Ethernet a prideľovanie adries, izolácia a akákoľvek politika 2. vrstvy sa teraz vzťahujú na nich. Zapíšte zvolený riadok do záznamu o zmene. Veta ako „smerovaný TUN, klientsky pool 10.90.0.0/24, spätná trasa na jadre“ zabráni ďalšiemu inžinierovi znova rozoberať návrh z nastavení port group.
Kto smie vidieť čie rámce
Položte vlastníkovi platformy jednu otázku, skôr než sa dotknete port group: vyžaduje návrh, aby tento VM prijímal rámce adresované iným účastníkom? Ak je odpoveď nie, nič v tejto časti sa neuplatní, pretože smerovaný TUN takú viditeľnosť nikdy nepotrebuje. Ak je odpoveď áno, pokyny Broadcomu k promiskuitnému režimu sú to pravé čítanie: vysvetľujú, koľko viac z vSwitch VM vidí, a odporúčajú obmedziť túto politiku na jednu port group.
Berte to ako kontrolu požiadavky, nie ako povolenie. Zapnite nastavenie pre jedno vyhradené pripojenie, keď je potreba mostovania zapísaná, a všade inde ho nechajte vypnuté. Široký VLAN trunk skopírovaný z iného príkladu mosta je časť, ktorú nikto nezabudne odstrániť, a návrh s jedným VLAN má zostať s jedným VLAN.
Zaznamenajte, ktorá port group sa zmenila a prečo, na to isté miesto, kam ste zapísali riadok návrhu. Práve tá dvojica umožňuje ďalší audit.
Udržujte objekty hosťa explicitné
V Linuxe sú členstvo v moste a vlastníctvo adresy oddelené objekty a ich miešanie spôsobuje mätúci polofunkčný stav. Prideľujte adresy rozhraniu mosta alebo smerovanému tunelu, nie obom stranám tej istej cesty, a členské porty držte bez IP konfigurácie.
Vyhnite sa umiestneniu jednej podsiete nezávisle na smerovanom TUN a na nesúvisiacom Ethernet rozhraní. Taká konfigurácia vytvára dve cesty k rovnakému prefixu, asymetrické odpovede a vlákno podpory o flappingu, ktoré nespomína ani jednu cestu. Ak hosť hostuje aj kontajnery alebo lokálny hypervisor, skontrolujte, že už nemostujú do rovnakého uplinku. Dva mosty na jednej NIC sú návrh, nie nehoda, ktorú chcete objaviť počas zmenového okna.
Potvrďte cestou paketu, nie pingom
Overte skutočnú cestu, nielen dosiahnuteľnosť. Z klienta potvrďte, ktorá zdrojová adresa dorazí do vzdialenej služby, a potom že odpoveď sa vracia tou istou cestou. Na hostovi skontrolujte počítadlá preposielania pre konkrétny tok a na port group potvrďte, že nie je zapnutá žiadna ďalšia viditeľnosť nad rámec zvoleného návrhu.
Nakoniec otestujte smer zlyhania. Zastavte tunel alebo odpojte klienta a skontrolujte, že prevádzka ticho nespadá na smerovanú cestu, ktorú ste považovali za nevyužitú, pretože práve ten pád je spôsob, akým sa mostovaný návrh ticho stane nechceným smerovačom.