ESXi-gjest-VPN: rutting eller bro — bestem før portgruppa
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 portgruppa 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 portgruppa først, og designspørsmålet besvares etterpå, vanligvis etter en broadcast-storm. Arbeid deg 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 eieren av tjenesten; hypervisor-konfigurasjonen skal gjennomføre den, ikke tilfeldig fastsette den.
Kontroller hva den fjerne enden faktisk trenger
List opp tjenestene de eksterne klientene må nå, og protokollene de bruker. Er lista en håndfull TCP-tjenester på kjente prefikser, dekker rutting det. Trenger noe virkelig lag-2-naboskap — broadcast-avhengig oppdagelse, ikke-IP-protokoller, en enhet som ikke godtar en gateway — kan rutting ikke etterligne det, og det bør sies tidlig. Vær ærlig om ikke-IP-oppføringene på lista, for det er der et rutet design stille feiler en uke senere.
Kontroller 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å gjestsida | 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 |
Rutting 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 portgruppa: 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å portgruppa 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.