ESXi-gäst-VPN: routning eller bryggning — bestäm före portgruppen
En routad TUN behöver returvägar; en bryggad TAP behöver lag-2-räckvidd och en bredare portgruppspolicy. Fastställ rollen innan du utökar promiscuous-läget.
Routa paketen eller utöka Ethernet-domänen: ändringen av portgruppen följer på det valet. Sett från en applikation med en privat adress kan resultaten se identiska ut, medan hypervisorns krav inte alls liknar varandra. Därför utökas portgruppen först och designfrågan besvaras sedan, vanligtvis efter en broadcast-storm. Gå igenom dessa kontroller i ordning och stanna medan kravet ännu är oklart, för ingen portgruppsinställning reparerar en design som aldrig valdes.
Beslutet tillhör tjänstens ägare; hypervisor-konfigurationen ska genomföra det, inte av misstag fastställa det.
Kontrollera vad den bortre änden faktiskt behöver
Lista de tjänster som fjärrklienterna måste nå och de protokoll de använder. Är listan en handfull TCP-tjänster på kända prefix räcker routning. Om något verkligen behöver lag-2-grannskap — broadcastberoende upptäckt, icke-IP-protokoll, en enhet som inte accepterar en gateway — kan routning inte imitera det, och det bör sägas tidigt. Var ärlig om icke-IP-posterna i listan, för det är där en routad design tyst misslyckas en vecka senare.
Kontrollera sedan klientpoolen. En routad design behöver ett adressområde och en uttrycklig returväg på den bortre sidan; en bryggad design behöver att den utökade Ethernet-domänen äger adresstilldelning och isolering. Vad du än väljer måste någon utanför denna VM godta det.
Vad varje design kräver av det virtuella nätet
De två designerna skiljer sig i vad det virtuella nätet måste tåla, och tabellen är det kortaste sättet att se det:
| Design | Roll på gästsidan | Vad det virtuella nätet måste rymma | Felläge vid fel val |
|---|---|---|---|
| Routad TUN | Router mellan åtskilda prefix | En routad klientpool plus returvägar på den bortre sidan | Klienterna når gatewayen och når aldrig tjänsten bakom den |
| Bryggad TAP | Lag-2-brygga för de klienter som ansluter | Ytterligare Ethernet-identiteter, broadcast-trafik och VLAN-regler | vSwitch tappar ramar, eller designen kräver ett promiscuous-läge som ingen har godkänt |
Routning låter broadcast-domänen vara där den är och ger en naturlig plats att begränsa vilka tjänster som korsar gatewayen. Bryggning flyttar gränsen: klienterna blir deltagare i den utökade Ethernet-domänen, och adresstilldelning, isolering och varje lag-2-policy gäller nu dem. Skriv den valda raden i ändringsloggen. En mening som ”routad TUN, klientpool 10.90.0.0/24, returväg på kärnan” hindrar nästa ingenjör från att ta upp designfrågan igen utifrån portgruppsinställningarna.
Vem bör få se vems ramar
Ställ en fråga till plattformsägaren innan du rör portgruppen: kräver designen att denna VM tar emot ramar adresserade till andra deltagare? Är svaret nej gäller ingenting i det här avsnittet, för en routad TUN behöver aldrig den synligheten. Är svaret ja är Broadcoms vägledning om promiscuous-läget den läsning som spelar roll: den redogör för hur mycket mer av vSwitch VM:en kan se och rekommenderar att policyn begränsas till en portgrupp.
Behandla det som en kravkontroll, inte som ett tillstånd. Slå på inställningen för en dedikerad anslutning när bryggbehovet är nedskrivet, och låt den vara av överallt annars. En bred VLAN-trunk kopierad från ett annat bryggexempel är den del ingen kommer ihåg att ta bort, och en enkel-VLAN-design bör förbli enkel-VLAN.
Registrera vilken portgrupp som ändrades och varför, på samma ställe där du skrev designraden. Det paret gör nästa revision möjlig.
Håll gästens objekt explicita
Inne i Linux är bryggmedlemskap och adressägande separata objekt, och att blanda dem skapar det förvirrande halvfungerande tillståndet. Tilldela adresser till bryggans gränssnitt eller den routade tunneln, inte till båda sidor av samma väg, och håll medlemsportarna fria från IP-konfiguration.
Undvik att lägga ett subnät oberoende på en routad TUN och på ett orelaterat Ethernet-gränssnitt. Den konfigurationen ger två vägar till samma prefix, asymmetriska svar och en supporttråd om flapping som aldrig nämner någon av vägarna. Om gästen också är värd för containrar eller en lokal hypervisor, kontrollera att de inte redan bryggar in i samma uplink. Två bryggor på ett NIC är en design, inte en olycka du vill upptäcka i ett ändringsfönster.
Bekräfta med en paketväg, inte med en ping
Verifiera den faktiska vägen, inte bara räckvidden. Bekräfta från en klient vilken källadress som anländer till fjärrtjänsten, och sedan att svaret kommer tillbaka samma väg. På gästen kontrolleras vidarebefordringsräknarna för det specifika flödet, och på portgruppen bekräftas att ingen extra synlighet har aktiverats utöver vad den valda designen kräver.
Testa slutligen felriktningen. Stoppa tunneln eller koppla från klienten och kontrollera att trafiken inte tyst faller tillbaka på en routad väg som du trodde var oanvänd, för det fallet är hur en bryggad design tyst blir en oavsiktlig router.