ESXi-gæste-VPN: routing eller bro — beslut inden portgruppen
En routet TUN kræver returruter; en broet TAP kræver lag-2-rækkevidde og en bredere portgruppepolitik. Fastlæg rollen, før du udvider promiscuous-tilstand.
Rut pakkerne eller udvid Ethernet-domænet: ændringen af portgruppen kommer efter det valg. Set fra en applikation med en privat adresse kan resultaterne se identiske ud, mens hypervisorens krav slet ikke ligner hinanden. Derfor udvides portgruppen først, og designspørgsmålet besvares bagefter, normalt efter en broadcast-storm. Gå disse kontroller igennem i rækkefølge, og stop mens kravet stadig er uklart, for ingen portgruppeindstilling retter et design, der aldrig blev valgt.
Beslutningen tilhører tjenestens ejer; hypervisor-konfigurationen skal implementere den, ikke tilfældigt fastlægge den.
Undersøg, hvad den fjerne ende faktisk har brug for
List de tjenester, de eksterne klienter skal nå, og de protokoller, de bruger. Er listen en håndfuld TCP-tjenester på kendte præfikser, dækker routing det. Har noget reelt brug for lag-2-naboskab — broadcast-afhængig opdagelse, ikke-IP-protokoller, en enhed der ikke accepterer en gateway — kan routing ikke efterligne det, og det bør siges tidligt. Vær ærlig om ikke-IP-posterne på listen, for det er der, et routet design stille fejler en uge senere.
Undersøg derefter klientpuljen. Et routet design kræver et adresseområde og en eksplicit returrute i den fjerne ende; et broet design kræver, at det udvidede Ethernet-domæne ejer adressetildeling og isolering. Uanset hvad du vælger, skal nogen uden for denne VM acceptere det.
Hvad hvert design kræver af det virtuelle netværk
De to designs adskiller sig i, hvad det virtuelle netværk skal tåle, og tabellen er den korteste måde at se det på:
| Design | Rolle på gæstesiden | Hvad det virtuelle netværk skal rumme | Fejltilstand ved forkert valg |
|---|---|---|---|
| Routet TUN | Router mellem adskilte præfikser | En routet klientpulje plus returveje i den fjerne ende | Klienterne når gatewayen og når aldrig tjenesten bag den |
| Broet TAP | Lag-2-bro for de klienter, der tilslutter sig | Ekstra Ethernet-identiteter, broadcast-trafik og VLAN-regler | vSwitch dropper rammer, eller designet kræver promiscuous-tilstand, som ingen har godkendt |
Routing holder broadcast-domænet, hvor det er, og giver et naturligt sted at begrænse, hvilke tjenester der krydser gatewayen. Broing flytter grænsen: klienterne bliver deltagere i det udvidede Ethernet-domæne, og adressetildeling, isolering og enhver lag-2-politik gælder nu for dem. Skriv den valgte række i ændringsregistret. En sætning som “routet TUN, klientpulje 10.90.0.0/24, returrute på kernen” forhindrer den næste ingeniør i at genoptage designdebatten ud fra portgruppeindstillingerne.
Hvem bør have lov til at se hvis rammer
Stil platformsejeren ét spørgsmål, før du rører portgruppen: kræver designet, at denne VM modtager rammer adresseret til andre deltagere? Er svaret nej, gælder intet i dette afsnit, for en routet TUN har aldrig brug for den synlighed. Er svaret ja, er Broadcoms vejledning om promiscuous-tilstand den læsning, der betyder noget: den redegør for, hvor meget mere af vSwitch VM'en kan se, og anbefaler at begrænse politikken til én portgruppe.
Behandl det som en kravkontrol, ikke en tilladelse. Slå indstillingen til for én dedikeret tilslutning, når brobehovet er skrevet ned, og lad den være slukket alle andre steder. En bred VLAN-trunk kopieret fra et andet broeksempel er den del, ingen husker at fjerne, og et enkelt-VLAN-design bør forblive enkelt-VLAN.
Registrer, hvilken portgruppe der blev ændret og hvorfor, samme sted hvor du skrev designrækken. Det par gør den næste revision mulig.
Hold gæstens objekter eksplicitte
Inde i Linux er bromedlemskab og adresseejerskab separate objekter, og at blande dem skaber den forvirrende halvt fungerende tilstand. Tildel adresser til brointerfacet eller til den routed tunnel, ikke til begge sider af samme vej, og hold medlemsportene fri for IP-konfiguration.
Undgå at lægge et undernet uafhængigt på en routet TUN og på et urelateret Ethernet-interface. Den konfiguration giver to veje til samme præfiks, asymmetriske svar og en supporttråd om flapping, der aldrig nævner nogen af vejene. Hvis gæsten også hoster containere eller en lokal hypervisor, så kontroller, at de ikke allerede broer ind i samme uplink. To broer på ét NIC er et design, ikke et uheld, du vil opdage i et ændringsvindue.
Bekræft med en pakkevej, ikke et ping
Verificér den faktiske vej, ikke kun rækkevidden. Bekræft fra en klient, hvilken kildeadresse der ankommer til den fjerne tjeneste, og bekræft derefter, at svaret vender tilbage samme vej. På gæsten kontrolleres videresendelsestællerne for den konkrete strøm, og på portgruppen bekræftes det, at der ikke er aktiveret ekstra synlighed ud over, hvad det valgte design kræver.
Test til sidst fejlretningen. Stop tunnelen, eller afbryd klienten, og kontroller, at trafikken ikke stille falder tilbage til en routet vej, som du troede var ubrugt, for det fald er, hvordan et broet design stille bliver en utilsigtet router.