ESXi-gas-VPN: roeteer of brug, besluit voor die portgroep
'n Gerouteerde TUN het terugroetes nodig; 'n gebrugde TAP het laag-2-bereik en 'n wyer portgroepbeleid nodig. Bepaal die rol voordat jy promisku modus verbreed.
Roeteer die pakkette of brei die Ethernet-domein uit: die portgroepverandering volg op daardie keuse. Vanuit 'n toepassing met 'n private adres kan die resultate identies lyk, terwyl die hipervisor-vereistes heeltemal verskil. Daarom word die portgroep eerste verbreed en die ontwerpvraag tweede beantwoord, gewoonlik ná 'n uitsaaistorm. Werk hierdie kontroles in volgorde deur en stop terwyl die vereiste nog vaag is, want geen portgroepinstelling regstel 'n ontwerp wat nooit gekies is nie.
Die besluit behoort aan die eienaar van die diens; die hipervisor-konfigurasie moet dit implementeer, nie per ongeluk bepaal nie.
Kontroleer wat die ander kant werklik nodig het
Lys die dienste wat die afgeleë kliënte moet bereik en die protokolle wat hulle gebruik. As die lys 'n handjievol TCP-dienste op bekende voorvoegsels is, dek roetering dit. As iets werklik laag-2-aangrensing nodig het — uitsaaiafhanklike ontdekking, nie-IP-protokolle, 'n toestel wat nie 'n poortweg wil aanvaar nie — kan roetering dit nie naboots nie en moet jy dit vroeg sê. Wees eerlik oor die nie-IP-inskrywings op daardie lys, want dit is waar 'n roeteringontwerp 'n week later stilweg faal.
Kontroleer dan die kliëntpoel. 'n Gerouteerde ontwerp het 'n adresreeks en 'n eksplisiete terugroete aan die ander kant nodig; 'n gebrugde ontwerp het die uitgebreide Ethernet-domein nodig om adrestoewysing en isolasie te besit. Watter een jy ook kies, iemand buite hierdie VM moet dit aanvaar.
Wat elke ontwerp van die virtuele netwerk vra
Die twee ontwerpe verskil in wat die virtuele netwerk moet verdra, en die tabel is die kortste manier om dit te sien:
| Ontwerp | Rol aan gasheerkant | Wat die virtuele netwerk moet akkommodeer | Foutmodus as jy verkeerd kies |
|---|---|---|---|
| Gerouteerde TUN | Roeteerder tussen aparte voorvoegsels | 'n Gerouteerde kliëntpoel plus terugpaaie aan die ander kant | Kliënte bereik die poortweg en bereik nooit die diens daar agter nie |
| Gebrugde TAP | Laag-2-brug vir die kliënte wat aansluit | Ekstra Ethernet-identiteite, uitsaaiverkeer en VLAN-reëls | Die vSwitch laat val rame, of die ontwerp vereis promisku modus wat niemand goedgekeur het nie |
Roetering hou die uitsaaidomein waar dit is en gee jou 'n natuurlike plek om te beperk watter dienste die poortweg oorsteek. Brugging verskuif die grens: die kliënte word deelnemers aan die uitgebreide Ethernet-domein, en adrestoewysing, isolasie en enige laag-2-beleid geld nou vir hulle. Skryf die gekose ry in die veranderingsrekord. 'n Sin soos “gerouteerde TUN, kliëntpoel 10.90.0.0/24, terugroete op die kern” verhoed dat die volgende ingenieur die ontwerp weer vanuit die portgroepinstellings betwis.
Wie mag sien wie se rame
Vra die platformeienaar een vraag voordat jy aan die portgroep raak: vereis die ontwerp dat hierdie VM rame ontvang wat aan ander deelnemers gerig is? As die antwoord nee is, geld niks in hierdie afdeling nie, want 'n gerouteerde TUN het nooit daardie sigbaarheid nodig nie. As die antwoord ja is, is die Broadcom-riglyn vir promisku modus die leesstof wat saak maak: dit uiteen hoe veel meer van die vSwitch die VM kan sien en beveel aan om daardie beleid tot een portgroep te beperk.
Behandel dit as 'n vereiste-kontrole, nie 'n toestemmingsbriefie nie. Skakel die instelling aan vir een toegewyde aanhegting wanneer die bruggingsbehoefte neergeskryf is, en laat dit oral anders af. 'n Breë VLAN-trunk wat uit 'n ander brugvoorbeeld gekopieer is, is die deel wat niemand onthou om te verwyder nie, en 'n enkel-VLAN-ontwerp moet enkel-VLAN bly.
Teken aan watter portgroep verander het en waarom, op dieselfde plek waar jy die ontwerpry neergeskryf het. Daardie koppeling maak die volgende oudit moontlik.
Hou die gas se objekte eksplisiet
Binne Linux is brugglidmaatskap en adresbesit aparte objekte, en om hulle te verwar veroorsaak die verwarrende halfwerkende toestand. Wys adresse toe aan die brugkoppelvlak of aan die gerouteerde tonnel, nie aan beide kante van dieselfde pad nie, en hou die lidpoorte vry van IP-konfigurasie.
Vermy om een subnet onafhanklik op 'n gerouteerde TUN en op 'n onverwante Ethernet-koppelvlak te plaas. Daardie konfigurasie lewer twee paaie na dieselfde voorvoegsel, asimmetriese antwoorde, en 'n ondersteuningsdraad oor flapping wat nooit een van die paaie noem nie. As die gas ook houers of 'n plaaslike hipervisor huisves, kontroleer dat hulle nie reeds in dieselfde uplink brug nie. Twee brûe op een NIC is 'n ontwerp, nie 'n ongeluk wat jy tydens 'n veranderingsvenster wil ontdek nie.
Bevestig met 'n pakketpad, nie 'n ping nie
Verifieer die werklike pad, nie net bereikbaarheid nie. Bevestig by 'n kliënt watter bronadres by die verre diens aankom, en bevestig dan dat die antwoord dieselfde pad terugkeer. Kyk op die gas na die deurstuur-tellers vir die spesifieke vloei, en bevestig op die portgroep dat geen bykomende sigbaarheid geaktiveer is bo wat die gekose ontwerp nodig het nie.
Toets laastens die foutrigting. Stop die tonnel of ontkoppel die kliënt en kyk dat verkeer nie stilweg terugval na 'n gerouteerde pad wat jy as ongebruik beskou het nie, want daardie terugval is hoe 'n gebrugde ontwerp stilweg 'n onbedoelde roeteerder word.