ESXi viesa VPN: maršrutēšana vai tiltošana — izlemiet pirms portu grupas
Maršrutētam TUN vajadzīgi atgriešanās maršruti; tiltotam TAP — 2. līmeņa sasniedzamība un plašāka portu grupas politika. Nosakiet lomu pirms promiscuous režīma paplašināšanas.
Maršrutējiet paketes vai paplašiniet Ethernet domēnu: portu grupas izmaiņas nāk pēc šīs izvēles. No lietojumprogrammas ar privātu adresi rezultāti var izskatīties identiski, kamēr hipervizora prasības nemaz nav līdzīgas. Tāpēc vispirms paplašina portu grupu, bet dizaina jautājums tiek atbildēts otrais, parasti pēc broadcast vētras. Veiciet šīs pārbaudes pēc kārtas un apstājieties, kamēr prasība vēl ir neskaidra, jo neviens portu grupas iestatījums nelabo dizainu, kas nekad netika izvēlēts.
Lēmums pieder pakalpojuma īpašniekam; hipervizora konfigurācijai tas jāīsteno, nevis nejauši jānosaka.
Pārbaudiet, kas tālajam galam patiešām vajadzīgs
Uzskaitiet pakalpojumus, kuri jāsasniedz attālinātajiem klientiem, un protokolus, ko viņi izmanto. Ja saraksts ir daži TCP pakalpojumi zināmos prefiksos, maršrutēšana ar to pietiek. Ja kaut kam patiešām vajadzīga 2. līmeņa blakusatbilstība — no broadcast atkarīga atklāšana, ne-IP protokoli, ierīce, kas nepieņem vārteju — maršrutēšana to nevar atdarināt, un tas jāsaka agri. Esiet godīgi par ne-IP ierakstiem šajā sarakstā, jo tieši tur maršrutēts dizains pēc nedēļas klusi neizdodas.
Pēc tam pārbaudiet klientu kopu. Maršrutētam dizainam vajadzīgs adrešu diapazons un skaidrs atgriešanās maršruts tālajā pusē; tiltotam dizainam vajadzīgs, lai paplašinātais Ethernet domēns pārvaldītu adrešu sadali un izolāciju. Ko vien izvēlaties, kādam ārpus šī VM tam jāpiekrīt.
Ko katrs dizains prasa no virtuālā tīkla
Abi dizaini atšķiras ar to, kas virtuālajam tīklam jāiztur, un tabula ir īsākais veids, kā to redzēt:
| Dizains | Loma viesa pusē | Kas virtuālajam tīklam jāuzņem | Kļūmes režīms nepareizas izvēles gadījumā |
|---|---|---|---|
| Maršrutēts TUN | Maršrutētājs starp atsevišķiem prefiksiem | Maršrutēta klientu kopa un atgriešanās ceļi tālajā pusē | Klienti sasniedz vārteju un nekad nesasniedz pakalpojumu aiz tās |
| Tiltots TAP | 2. līmeņa tilts klientiem, kas pievienojas | Papildu Ethernet identitātes, broadcast trafiks un VLAN noteikumi | vSwitch izmet kadrus, vai dizainam vajadzīgs promiscuous režīms, ko neviens nav apstiprinājis |
Maršrutēšana atstāj broadcast domēnu tur, kur tas ir, un dod dabisku vietu ierobežot, kuri pakalpojumi šķērso vārteju. Tiltēšana pārvieto robežu: klienti kļūst par paplašinātā Ethernet domēna dalībniekiem, un adrešu sadale, izolācija un jebkura 2. līmeņa politika tagad attiecas uz viņiem. Ierakstiet izvēlēto rindu izmaiņu žurnālā. Teikums kā „maršrutēts TUN, klientu kopa 10.90.0.0/24, atgriešanās maršruts kodolā“ neļauj nākamajam inženierim no jauna apspriest dizainu, balstoties uz portu grupas iestatījumiem.
Kam jābūt tiesībām redzēt kā kadrus
Pirms portu grupas aizskaršanas uzdodiet platformas īpašniekam vienu jautājumu: vai dizains prasa, lai šis VM saņemtu kadrus, kas adresēti citiem dalībniekiem? Ja atbilde ir nē, šajā sadaļā nekas neattiecas, jo maršrutētam TUN šāda redzamība nekad nav vajadzīga. Ja atbilde ir jā, tad Broadcom promiscuous režīma vadlīnijas ir tas lasāmais, kam ir nozīme: tajā paskaidrots, cik daudz vairāk no vSwitch VM redz, un ieteikts šo politiku ierobežot ar vienu portu grupu.
Uztveriet to kā prasības pārbaudi, nevis atļauju. Ieslēdziet iestatījumu vienam dedicated savienojumam, kad tiltēšanas vajadzība ir pierakstīta, un visur citur atstājiet to izslēgtu. Plašs VLAN trunk, kas nokopēts no cita tilta piemēra, ir tā daļa, ko neviens neatceras noņemt, un viena VLAN dizainam jāpaliek viena VLAN.
Ierakstiet, kura portu grupa mainījās un kāpēc, tajā pašā vietā, kur ierakstījāt dizaina rindu. Tieši šis pāris padara iespējamu nākamo auditu.
Turiet viesa objektus skaidrus
Linux iekšienē tilta dalība un adreses īpašumtiesības ir atsevišķi objekti, un to sajaukšana rada mulsinošo daļēji strādājošo stāvokli. Piešķiriet adreses tilta saskarnei vai maršrutētajam tunelim, nevis abām viena ceļa pusēm, un turiet dalībnieku portus bez IP konfigurācijas.
Izvairieties vienu apakštīklu neatkarīgi likt uz maršrutēta TUN un uz nesaistītas Ethernet saskarnes. Šāda konfigurācija rada divus ceļus uz to pašu prefiksu, asimetriskas atbildes un atbalsta pavedienu par flapping, kas nemin nevienu no ceļiem. Ja viesis mitina arī konteinerus vai vietēju hipervizoru, pārbaudiet, vai tie jau nav tiltoti tajā pašā uplink. Divi tilti uz vienas NIC ir dizains, nevis nelaime, ko vēlaties atklāt izmaiņu logā.
Apstipriniet ar paketes ceļu, nevis ping
Pārbaudiet faktisko ceļu, ne tikai sasniedzamību. No klienta apstipriniet, kura avota adrese nonāk tālajā pakalpojumā, un pēc tam, ka atbilde atgriežas pa to pašu ceļu. Uz viesa pārbaudiet konkrētās plūsmas pārsūtīšanas skaitītājus, bet portu grupā apstipriniet, ka nav iespējota papildu redzamība, kas pārsniedz izvēlētā dizaina vajadzības.
Visbeidzot pārbaudiet kļūmes virzienu. Apturiet tuneli vai atvienojiet klientu un pārbaudiet, vai trafiks klusi nekrīt atpakaļ uz maršrutētu ceļu, ko uzskatījāt par neizmantotu, jo tieši šī krišana ir veids, kā tiltots dizains klusi kļūst par nevēlamu maršrutētāju.