ESXi-gast-VPN: routeren of bridgen — beslis vóór de portgroep
Een gerouteerde TUN heeft retourroutes nodig; een gebrugde TAP heeft layer-2-bereik en een breder portgroepbeleid nodig. Bepaal de rol voordat u de promiscuous-modus verbreedt.
Routeer de pakketten of breid het Ethernet-domein uit: de wijziging van de portgroep volgt op die keuze. Vanuit een applicatie met een privéadres kunnen de resultaten identiek lijken, terwijl de eisen van de hypervisor totaal verschillen. Daarom wordt de portgroep eerst verbreed en de ontwerpvraag daarna beantwoord, meestal na een broadcast-storm. Doorloop deze controles in volgorde en stop zolang de eis nog vaag is, want geen enkele portgroepinstelling repareert een ontwerp dat nooit is gekozen.
De beslissing is van de eigenaar van de dienst; de hypervisorconfiguratie moet die uitvoeren, niet per ongeluk bepalen.
Controleer wat de verre kant echt nodig heeft
Som de diensten op die de externe clients moeten bereiken en de protocollen die ze gebruiken. Is de lijst een handvol TCP-diensten op bekende prefixen, dan dekt routering dat. Heeft iets echt layer-2-nabijheid nodig — broadcastafhankelijke ontdekking, niet-IP-protocollen, een apparaat dat geen gateway accepteert — dan kan routering dat niet nabootsen en moet dat vroeg gezegd worden. Wees eerlijk over de niet-IP-vermeldingen op die lijst, want daar faalt een gerouteerd ontwerp een week later stilletjes.
Controleer daarna de clientpool. Een gerouteerd ontwerp heeft een adresbereik en een expliciete retourroute aan de verre kant nodig; een gebrugd ontwerp heeft een uitgebreid Ethernet-domein nodig dat adrestoewijzing en isolatie bezit. Wat u ook kiest, iemand buiten deze VM moet ermee instemmen.
Wat elk ontwerp van het virtuele netwerk vraagt
De twee ontwerpen verschillen in wat het virtuele netwerk moet verdragen, en de tabel is de kortste manier om dat te zien:
| Ontwerp | Rol aan gastzijde | Wat het virtuele netwerk moet opvangen | Faalmodus bij verkeerde keuze |
|---|---|---|---|
| Gerouteerde TUN | Router tussen gescheiden prefixen | Een gerouteerde clientpool plus retourpaden aan de verre kant | Clients bereiken de gateway en bereiken nooit de dienst erachter |
| Gebrugde TAP | Layer-2-brug voor de clients die toetreden | Extra Ethernet-identiteiten, broadcastverkeer en VLAN-regels | De vSwitch laat frames vallen, of het ontwerp vraagt een promiscuous-modus die niemand heeft goedgekeurd |
Routering laat het broadcast-domein waar het is en geeft een natuurlijke plek om te beperken welke diensten de gateway passeren. Bridging verschuift de grens: de clients worden deelnemers aan het uitgebreide Ethernet-domein, en adrestoewijzing, isolatie en elk layer-2-beleid gelden nu voor hen. Schrijf de gekozen rij in het wijzigingsregister. Een zin als ‘gerouteerde TUN, clientpool 10.90.0.0/24, retourroute op de core’ voorkomt dat de volgende engineer het ontwerp opnieuw bediscussieert vanuit de portgroepinstellingen.
Wie mag wiens frames zien
Stel de platformeigenaar één vraag voordat u de portgroep aanraakt: vereist het ontwerp dat deze VM frames ontvangt die aan andere deelnemers zijn geadresseerd? Is het antwoord nee, dan geldt niets in deze sectie, want een gerouteerde TUN heeft die zichtbaarheid nooit nodig. Is het antwoord ja, dan is de Broadcom-richtlijn over de promiscuous-modus de lectuur die ertoe doet: die zet uiteen hoeveel meer van de vSwitch de VM kan zien en adviseert dat beleid tot één portgroep te beperken.
Behandel dit als een eiscontrole, niet als een vergunning. Zet de instelling aan voor één toegewezen aansluiting wanneer de brugbehoefte is opgeschreven, en laat hem overal elders uit. Een brede VLAN-trunk die uit een ander brugvoorbeeld is gekopieerd, is het deel dat niemand denkt te verwijderen, en een ontwerp met één VLAN moet één VLAN blijven.
Leg vast welke portgroep is gewijzigd en waarom, op dezelfde plek als de ontwerpregel. Die combinatie maakt de volgende audit mogelijk.
Houd de objecten van de gast expliciet
Binnen Linux zijn brugdeelname en adreseigendom aparte objecten, en het door elkaar halen ervan veroorzaakt de verwarrende halfwerkende toestand. Wijs adressen toe aan de bruginterface of aan de gerouteerde tunnel, niet aan beide zijden van hetzelfde pad, en houd de lidpoorten vrij van IP-configuratie.
Vermijd om één subnet onafhankelijk op een gerouteerde TUN en op een niet-gerelateerde Ethernet-interface te zetten. Die configuratie levert twee paden naar hetzelfde prefix, asymmetrische antwoorden en een supportthread over flapping die geen van beide paden noemt. Als de gast ook containers of een lokale hypervisor host, controleer dan dat ze niet al naar dezelfde uplink bruggen. Twee bruggen op één NIC zijn een ontwerp, geen ongeluk dat u tijdens een wijzigingsvenster wilt ontdekken.
Bevestig met een pakketpad, niet met een ping
Controleer het werkelijke pad, niet alleen de bereikbaarheid. Bevestig vanaf een client welk bronadres bij de verre dienst aankomt, en daarna dat het antwoord dezelfde weg teruggaat. Controleer op de gast de doorstuurcounters voor de specifieke flow, en bevestig op de portgroep dat er geen extra zichtbaarheid is ingeschakeld boven wat het gekozen ontwerp nodig heeft.
Test ten slotte de faalrichting. Stop de tunnel of koppel de client los en controleer dat verkeer niet stilletjes terugvalt op een gerouteerd pad waarvan u dacht dat het ongebruikt was, want die terugval is hoe een gebrugd ontwerp stilletjes een onbedoelde router wordt.