ESXi-gjest-VPN: ruting eller bru — avgjer før portgruppa
Ein ruta TUN treng returruter; ein brua TAP treng lag-2-rekkjevidde og ein breiare portgruppepolicy. Fastset rolla før du utvidar promiscuous-modus.
Rut pakkane eller utvid Ethernet-domenet: endringa av portgruppa kjem etter det valet. Sett frå ein applikasjon med ei privat adresse kan resultata sjå identiske ut, medan krava til hypervisoren slett ikkje liknar kvarandre. Derfor blir portgruppa utvida først, og designspørsmålet blir svara på etterpå, vanlegvis etter ein broadcast-storm. Gå gjennom desse kontrollane i rekkjefølgje og stopp medan kravet enno er uklart, for inga portgruppeinnstilling reparerer eit design som aldri vart valt.
Avgjerda høyrer til eigaren av tenesta; hypervisor-konfigurasjonen skal gjennomføre henne, ikkje tilfeldig fastsetje henne.
Sjekk kva den fjerne enden faktisk treng
List opp tenestene dei eksterne klientane må nå, og protokollane dei brukar. Er lista ei handfull TCP-tenester på kjende prefiks, dekkjer ruting det. Treng noko verkeleg lag-2-naboskap — broadcast-avhengig oppdaging, ikkje-IP-protokollar, ei eining som ikkje godtek ein gateway — kan ruting ikkje etterlikne det, og det bør seiast tidleg. Ver ærleg om ikkje-IP-oppføringane på lista, for det er der eit ruta design stille feilar ei veke seinare.
Sjekk deretter klientpoolen. Eit ruta design treng eit adresseområde og ei eksplisitt returrute i den fjerne enden; eit brua design treng at det utvida Ethernet-domenet eig adressetildeling og isolasjon. Uansett kva du vel, må nokon utanfor denne VM-en godta det.
Kva kvart design krev av det virtuelle nettet
Dei to designa skil seg i kva det virtuelle nettet må tole, og tabellen er den kortaste måten å sjå det på:
| Design | Rolle på gjestsida | Kva det virtuelle nettet må romme | Feilmodus ved feil val |
|---|---|---|---|
| Ruta TUN | Rutar mellom atskilde prefiks | Ein ruta klientpool pluss returvegar i den fjerne enden | Klientane når gatewayen og når aldri tenesta bak han |
| Brua TAP | Lag-2-bru for klientane som koplar seg til | Ekstra Ethernet-identitetar, broadcast-trafikk og VLAN-reglar | vSwitch droppar rammer, eller designet krev promiscuous-modus som ingen har godkjent |
Ruting lèt broadcast-domenet bli der det er og gir ein naturleg stad å avgrense kva tenester som kryssar gatewayen. Bruing flyttar grensa: klientane blir deltakarar i det utvida Ethernet-domenet, og adressetildeling, isolasjon og kva som helst lag-2-policy gjeld no for dei. Skriv den valde rada i endringsloggen. Ei setning som «ruta TUN, klientpool 10.90.0.0/24, returrute på kjernen» hindrar den neste ingeniøren i å ta opp att designdebatten ut frå portgruppeinnstillingane.
Kven bør få sjå kven sine rammer
Still plattformeigaren eitt spørsmål før du rører portgruppa: krev designet at denne VM-en tek imot rammer adresserte til andre deltakarar? Er svaret nei, gjeld ingenting i dette avsnittet, for ein ruta TUN treng aldri den synlegheita. Er svaret ja, er rettleiinga frå Broadcom om promiscuous-modus det som er verdt å lese: ho gjer greie for kor mykje meir av vSwitch-en VM-en kan sjå, og tilrår å avgrense policyen til éi portgruppe.
Behandle dette som ein kravkontroll, ikkje ei løyve. Slå innstillinga på for éin dedikert tilkopling når bruhovet er skrive ned, og la henne vere av alle andre stader. Ein brei VLAN-trunk kopiert frå eit anna brueksempel er den delen ingen hugsar å fjerne, og eit enkelt-VLAN-design bør halde fram som enkelt-VLAN.
Registrer kva portgruppe som vart endra og kvifor, på same staden der du skreiv designrada. Det paret gjer den neste revisjonen mogleg.
Hald objekta til gjesten eksplisitte
Inne i Linux er brumateriale og adresseeige separate objekt, og å blande dei skaper den forvirrande halvfungerande tilstanden. Tildel adresser til brugrensesnittet eller den ruta tunnelen, ikkje til begge sider av same veg, og hald medlemsportane fri for IP-konfigurasjon.
Unngå å leggje eitt subnett uavhengig på ein ruta TUN og på eit urelatert Ethernet-grensesnitt. Den konfigurasjonen gir to vegar til same prefiks, asymmetriske svar og ein støttetråd om flapping som aldri nemner nokon av vegane. Viss gjesten også er vert for containerar eller ein lokal hypervisor, sjekk at dei ikkje allereie bruar inn i same uplink. To bruer på éin NIC er eit design, ikkje ei ulukke du vil oppdage i eit endringsvindauge.
Stadfest med ein pakkeveg, ikkje ein ping
Verifiser den faktiske vegen, ikkje berre rekkjevidda. Stadfest frå ein klient kva kjeldeadresse som kjem fram til den fjerne tenesta, og deretter at svaret kjem tilbake same veg. På gjesten blir vidaresendingsteljarane for den konkrete straumen kontrollerte, og på portgruppa blir det stadfesta at inga ekstra synlegheit er aktivert ut over det det valde designet krev.
Til slutt, test feilretninga. Stopp tunnelen eller kople frå klienten, og kontroller at trafikken ikkje stille fell tilbake til ein ruta veg du trudde var ubrukt, for det fallet er korleis eit brua design stille blir ein utilsikta rutar.