ESXi-gjest-VPN: ruting eller bro — bestem før portgruppen
En rutet TUN trenger returruter; en broet TAP trenger lag-2-rekkevidde og en bredere portgruppepolicy. Fastsett rollen før du utvider promiscuous-modus.
Rut pakkene eller utvid Ethernet-domenet: endringen av portgruppen kommer etter det valget. Sett fra en applikasjon med en privat adresse kan resultatene se identiske ut, mens hypervisorens krav slett ikke ligner hverandre. Derfor utvides portgruppen først, og designspørsmålet besvares etterpå, vanligvis etter en broadcast-storm. Gå gjennom disse kontrollene i rekkefølge og stopp mens kravet ennå er uklart, for ingen portgruppeinnstilling reparerer et design som aldri ble valgt.
Beslutningen tilhører tjenestens eier; hypervisor-konfigurasjonen skal implementere den, ikke tilfeldig fastsette den.
Sjekk hva den fjerne enden faktisk trenger
List opp tjenestene de eksterne klientene må nå, og protokollene de bruker. Er listen en håndfull TCP-tjenester på kjente prefikser, dekker ruting det. Trenger noe virkelig lag-2-naboskap — broadcast-avhengig oppdagelse, ikke-IP-protokoller, en enhet som ikke godtar en gateway — kan ruting ikke etterligne det, og det bør sies tidlig. Vær ærlig om ikke-IP-oppføringene på listen, for det er der et rutet design stille feiler en uke senere.
Sjekk deretter klientpoolen. Et rutet design trenger et adresseområde og en eksplisitt returrute i den fjerne enden; et broet design trenger at det utvidede Ethernet-domenet eier adressetildeling og isolasjon. Uansett hva du velger, må noen utenfor denne VM-en godta det.
Hva hvert design krever av det virtuelle nettverket
De to designene skiller seg i hva det virtuelle nettverket må tåle, og tabellen er den korteste måten å se det på:
| Design | Rolle på gjestsiden | Hva det virtuelle nettverket må romme | Feilmodus ved feil valg |
|---|---|---|---|
| Rutet TUN | Ruter mellom atskilte prefikser | En rutet klientpool pluss returveier i den fjerne enden | Klientene når gatewayen og når aldri tjenesten bak den |
| Broet TAP | Lag-2-bro for klientene som kobler seg til | Ekstra Ethernet-identiteter, broadcast-trafikk og VLAN-regler | vSwitch dropper rammer, eller designet krever promiscuous-modus som ingen har godkjent |
Ruting lar broadcast-domenet bli der det er og gir et naturlig sted å begrense hvilke tjenester som krysser gatewayen. Broing flytter grensen: klientene blir deltakere i det utvidede Ethernet-domenet, og adressetildeling, isolasjon og enhver lag-2-policy gjelder nå for dem. Skriv den valgte raden i endringsloggen. En setning som «rutet TUN, klientpool 10.90.0.0/24, returrute på kjernen» hindrer den neste ingeniøren i å gjenoppta designdebatten ut fra portgruppeinnstillingene.
Hvem bør få se hvis rammer
Still plattformeieren ett spørsmål før du rører portgruppen: krever designet at denne VM-en mottar rammer adressert til andre deltakere? Er svaret nei, gjelder ingenting i dette avsnittet, for en rutet TUN trenger aldri den synligheten. Er svaret ja, er Broadcoms veiledning om promiscuous-modus det som er verdt å lese: den redegjør for hvor mye mer av vSwitch-en VM-en kan se, og anbefaler å begrense policyen til én portgruppe.
Behandle det som en kravkontroll, ikke en tillatelse. Slå innstillingen på for én dedikert tilkobling når brobehovet er skrevet ned, og la den være av alle andre steder. En bred VLAN-trunk kopiert fra et annet broeksempel er den delen ingen husker å fjerne, og et enkelt-VLAN-design bør forbli enkelt-VLAN.
Registrer hvilken portgruppe som ble endret og hvorfor, på samme sted der du skrev designraden. Det paret gjør den neste revisjonen mulig.
Hold gjestens objekter eksplisitte
Inne i Linux er bromedlemskap og adresseeierskap separate objekter, og å blande dem skaper den forvirrende halvfungerende tilstanden. Tildel adresser til brogrensesnittet eller den rutete tunnelen, ikke til begge sider av samme vei, og hold medlemsportene fri for IP-konfigurasjon.
Unngå å legge ett subnett uavhengig på en rutet TUN og på et urelatert Ethernet-grensesnitt. Den konfigurasjonen gir to veier til samme prefiks, asymmetriske svar og en støttetråd om flapping som aldri nevner noen av veiene. Hvis gjesten også er vert for containere eller en lokal hypervisor, sjekk at de ikke allerede broer inn i samme uplink. To broer på ett NIC er et design, ikke en ulykke du vil oppdage i et endringsvindu.
Bekreft med en pakkevei, ikke en ping
Verifiser den faktiske veien, ikke bare rekkevidden. Bekreft fra en klient hvilken kildeadresse som ankommer den fjerne tjenesten, og deretter at svaret kommer tilbake samme vei. På gjesten kontrolleres videresendingstellerne for den konkrete strømmen, og på portgruppen bekreftes det at ingen ekstra synlighet er aktivert ut over det det valgte designet krever.
Til slutt, test feilretningen. Stopp tunnelen eller koble fra klienten, og kontroller at trafikken ikke stille faller tilbake til en rutet vei du trodde var ubrukt, for det fallet er hvordan et broet design stille blir en utilsiktet ruter.