ESXi svečio VPN: maršrutizavimas ar tiltas — nuspręskite prieš prievadų grupę
Maršrutizuotas TUN reikalauja grįžimo maršrutų; tiltu sujungtas TAP reikalauja 2-ojo lygio pasiekiamumo ir platesnės prievadų grupės politikos. Nustatykite vaidmenį prieš išplėsdami promiscuous režimą.
Maršrutizuokite paketus arba išplėskite Ethernet domeną: prievadų grupės pakeitimas ateina po šio pasirinkimo. Programos su privačiu adresu požiūriu rezultatai gali atrodyti vienodi, o hipervizoriaus reikalavimai visiškai skirtingi. Todėl pirmiausia išplečiama prievadų grupė, o dizaino klausimas atsakomas vėliau, dažniausiai po broadcast audros. Atlikite šiuos patikrinimus iš eilės ir sustokite, kol reikalavimas dar neaiškus, nes jokia prievadų grupės nuostata nepataiso dizaino, kuris niekada nebuvo pasirinktas.
Sprendimas priklauso paslaugos savininkui; hipervizoriaus konfigūracija turi jį įgyvendinti, o ne netyčia nustatyti.
Patikrinkite, ko iš tikrųjų reikia tolimajam galui
Išvardykite paslaugas, kurias privalo pasiekti nuotoliniai klientai, ir protokolus, kuriuos jie naudoja. Jei sąrašas yra keli TCP servisai žinomuose prefiksuose, maršrutizavimas to pakanka. Jei kažkam tikrai reikia 2-ojo lygio gretimumo — nuo broadcast priklausomas aptikimas, ne IP protokolai, įrenginys, nepriimantis tinklų sietuvo — maršrutizavimas to negali imituoti, ir tai reikia pasakyti anksti. Būkite sąžiningi dėl ne IP įrašų tame sąraše, nes būtent ten maršrutizuotas dizainas po savaitės tyliai žlunga.
Tada patikrinkite klientų telkinį. Maršrutizuotam dizainui reikia adresų diapazono ir aiškaus grįžimo maršruto tolimoje pusėje; tiltu sujungtam dizainui reikia, kad išplėstas Ethernet domenas valdytų adresų paskirstymą ir izoliaciją. Kad ir ką pasirinktumėte, kažkas už šios VM ribų turi tam pritarti.
Ko kiekvienas dizainas reikalauja iš virtualaus tinklo
Du dizainai skiriasi tuo, ką virtualus tinklas turi iškęsti, o lentelė yra trumpiausias būdas tai pamatyti:
| Dizainas | Vaidmuo svečio pusėje | Ką virtualus tinklas turi sutalpinti | Gedimo režimas neteisingai pasirinkus |
|---|---|---|---|
| Maršrutizuotas TUN | Maršrutizatorius tarp atskirų prefiksų | Maršrutizuotas klientų telkinys ir grįžimo keliai tolimoje pusėje | Klientai pasiekia tinklų sietuvą ir niekada nepasiekia paslaugos už jo |
| Tiltu sujungtas TAP | 2-ojo lygio tiltas prisijungiantiems klientams | Papildomos Ethernet tapatybės, broadcast srautas ir VLAN taisyklės | vSwitch meta kadrus, arba dizainui reikia promiscuous režimo, kurio niekas nepatvirtino |
Maršrutizavimas palieka broadcast domeną ten, kur jis yra, ir suteikia natūralią vietą apriboti, kurios paslaugos kerta tinklų sietuvą. Tiltas perkelia ribą: klientai tampa išplėsto Ethernet domeno dalyviais, o adresų paskirstymas, izoliacija ir bet kokia 2-ojo lygio politika dabar jiems taikoma. Įrašykite pasirinktą eilutę į pakeitimų žurnalą. Sakinys kaip „maršrutizuotas TUN, klientų telkinys 10.90.0.0/24, grįžimo maršrutas branduolyje“ neleidžia kitam inžinieriui vėl svarstyti dizaino pagal prievadų grupės nustatymus.
Kas kam turi matyti kadrus
Užduokite platformos savininkui vieną klausimą prieš liesdami prievadų grupę: ar dizainas reikalauja, kad ši VM gautų kadrus, adresuotus kitiems dalyviams? Jei atsakymas ne, šiame skyriuje niekas netaikoma, nes maršrutizuotam TUN to matomumo niekada nereikia. Jei atsakymas taip, tai Broadcom promiscuous režimo gairės yra tas skaitinys, kuris svarbus: jis paaiškina, kiek daugiau vSwitch mato VM, ir rekomenduoja tą politiką apriboti viena prievadų grupe.
Traktuokite tai kaip reikalavimo patikrinimą, o ne leidimą. Įjunkite nuostatą vienam skirtam prisijungimui, kai tilto poreikis užrašytas, ir visur kitur palikite išjungtą. Platus VLAN trunk, nukopijuotas iš kito tilto pavyzdžio, yra ta dalis, kurios niekas nepamena pašalinti, o vieno VLAN dizainas turėtų likti vieno VLAN.
Užrašykite, kuri prievadų grupė pasikeitė ir kodėl, toje pačioje vietoje, kur užrašėte dizaino eilutę. Būtent ši pora leidžia atlikti kitą auditą.
Laikykite svečio objektus aiškiais
Linux viduje tilto narystė ir adreso nuosavybė yra atskiri objektai, o jų painiojimas sukelia klaidinančią pusiau veikiančią būseną. Priskirkite adresus tilto sąsajai arba maršrutizuotam tuneliui, o ne abiem to paties kelio pusėms, ir laikykite narių prievadus be IP konfigūracijos.
Venkite vieną potinklį savarankiškai dėti ant maršrutizuoto TUN ir ant nesusijusios Ethernet sąsajos. Tokia konfigūracija sukuria du kelius į tą patį prefiksą, asimetriškus atsakymus ir palaikymo giją apie flapping, kuri nemini nė vieno kelio. Jei svečias taip pat talpina konteinerius ar vietinį hipervizorių, patikrinkite, ar jie jau nesijungia tiltu į tą patį uplink. Du tiltai viename NIC yra dizainas, o ne nelaimė, kurią norite atrasti pakeitimų lange.
Patvirtinkite paketo keliu, o ne ping
Patikrinkite tikrąjį kelią, o ne tik pasiekiamumą. Iš kliento patvirtinkite, kuris šaltinio adresas atvyksta į tolimą paslaugą, tada kad atsakymas grįžta tuo pačiu keliu. Svečiame patikrinkite konkretaus srauto persiuntimo skaitiklius, o prievadų grupėje patvirtinkite, kad neįjungtas joks papildomas matomumas, viršijantis pasirinkto dizaino poreikį.
Galiausiai išbandykite gedimo kryptį. Sustabdykite tunelį arba atjunkite klientą ir patikrinkite, ar srautas tyliai nenukrenta į maršrutizuotą kelią, kurį laikėte nenaudojamu, nes būtent tas kritimas yra tai, kaip tiltu sujungtas dizainas tyliai tampa netyčiniu maršrutizatoriumi.