ESXi-vieras-VPN: reititys vai sillitys — päätä ennen porttiryhmää
Reititetty TUN tarvitsee paluureitit; sillitetty TAP tarvitsee layer 2 -ulottuvuuden ja laajemman porttiryhmäkäytännön. Määritä rooli ennen promiscuous-tilan laajentamista.
Reititä paketit tai laajenna Ethernet-aluetta: porttiryhmän muutos seuraa tästä valinnasta. Yksityisen osoitteen omaavan sovelluksen näkökulmasta tulokset voivat näyttää samoilta, kun taas hypervisorin vaatimukset eivät muistuta toisiaan lainkaan. Siksi porttiryhmä laajennetaan ensin ja suunnittelukysymykseen vastataan toiseksi, yleensä broadcast-myrskyn jälkeen. Käy nämä tarkistukset järjestyksessä läpi ja pysähdy, kun vaatimus on vielä epäselvä, sillä mikään porttiryhmän asetus ei korjaa suunnittelua, jota ei koskaan valittu.
Päätös kuuluu palvelun omistajalle; hypervisorin kokoonpanon on toteutettava se, ei määritettävä sitä vahingossa.
Tarkista, mitä kaukopää todella tarvitsee
Listaa palvelut, joihin etäasiakkaiden on päästävä, ja protokollat, joita he käyttävät. Jos lista on kourallinen TCP-palveluita tunnetuilla etuliitteillä, reititys kattaa sen. Jos jokin todella tarvitsee layer 2 -vierialueisuutta — broadcastista riippuvaa löytämistä, ei-IP-protokollia, laitetta joka ei hyväksy yhdyskäytävää — reititys ei voi jäljitellä sitä, ja se on sanottava varhain. Ole rehellinen listan ei-IP-kohdista, sillä juuri siellä reititetty suunnittelu pettää hiljaa viikkoa myöhemmin.
Tarkista sitten asiakasjoukko. Reititetty suunnittelu tarvitsee osoitealueen ja nimenomaisen paluureitin kaukopäässä; sillitetty suunnittelu tarvitsee laajennetun Ethernet-alueen, joka omistaa osoitteiden jakamisen ja eristyksen. Mitä tahansa valitsetkin, jonkun tämän VM:n ulkopuolella on hyväksyttävä se.
Mitä kukin suunnittelu vaatii virtuaaliverkolta
Kaksi suunnittelua eroavat siinä, mitä virtuaaliverkon on siedettävä, ja taulukko on lyhin tapa nähdä se:
| Suunnittelu | Rooli vieraan puolella | Mitä virtuaaliverkon on mahduttava | Vikatila väärällä valinnalla |
|---|---|---|---|
| Reititetty TUN | Reititin erillisten etuliitteiden välillä | Reititetty asiakasjoukko sekä paluureitit kaukopäässä | Asiakkaat saavuttavat yhdyskäytävän eivätkä koskaan sen takana olevaa palvelua |
| Sillitetty TAP | Layer 2 -silta liittyville asiakkaille | Ylimääräiset Ethernet-identiteetit, broadcast-liikenne ja VLAN-säännöt | vSwitch pudottaa kehyksiä, tai suunnittelu vaatii promiscuous-tilan, jota kukaan ei hyväksynyt |
Reititys pitää broadcast-alueen paikallaan ja antaa luonnollisen paikan rajoittaa, mitkä palvelut ylittävät yhdyskäytävän. Sillitys siirtää rajaa: asiakkaista tulee laajennetun Ethernet-alueen osallistujia, ja osoitteiden jakaminen, eristys ja kaikki layer 2 -käytäntö koskevat nyt heitä. Kirjoita valittu rivi muutoslokkiin. Lause kuten “reititetty TUN, asiakasjoukko 10.90.0.0/24, paluureitti ytimessä” estää seuraavaa insinööriä käymästä suunnittelua uudelleen läpi porttiryhmän asetuksista.
Kenen kehykset kuka saa nähdä
Kysy alustan omistajalta yksi kysymys ennen kuin kosket porttiryhmään: vaatiiko suunnittelu, että tämä VM vastaanottaa kehyksiä, jotka on osoitettu muille osallistujille? Jos vastaus on ei, mikään tässä osassa ei päde, sillä reititetty TUN ei koskaan tarvitse sitä näkyvyyttä. Jos vastaus on kyllä, Broadcomin promiscuous-tilan ohje on se luettava, jolla on merkitystä: se selvittää, kuinka paljon enemmän vSwitchistä VM näkee, ja suosittaa kyseisen käytännön rajaamista yhteen porttiryhmään.
Käsittele tätä vaatimuksen tarkistuksena, ei lupalappuna. Kytke asetus päälle yhdelle omistetulle liitännälle, kun sillitystarve on kirjattu, ja jätä se pois kaikkialta muualta. Toisesta siltäesimerkistä kopioitu leveä VLAN-trunk on se osa, jota kukaan ei muista poistaa, ja yhden VLAN:n suunnittelun pitäisi pysyä yhden VLAN:n suunnitteluna.
Kirjaa, mikä porttiryhmä muuttui ja miksi, samaan paikkaan johon kirjasit suunnittelurivin. Juuri tämä pari tekee seuraavan auditoinnin mahdolliseksi.
Pidä vieraan objektit selkeinä
Linuxin sisällä sillan jäsenyys ja osoitteen omistus ovat erillisiä objekteja, ja niiden sekoittaminen aiheuttaa hämmentävän puoliksi toimivan tilan. Anna osoitteet sillan liitännälle tai reititetylle tunnelille, älä saman polun molemmille puolille, ja pidä jäsenportit ilman IP-kokoonpanoa.
Vältä yhden aliverkon sijoittamista itsenäisesti reititetylle TUN:lle ja erilliselle Ethernet-liitännälle. Sellainen kokoonpano tuottaa kaksi polkua samaan etuliitteeseen, epäsymmetriset vastaukset ja tukiketjun flappingista, joka ei mainitse kumpaakaan polkua. Jos vieras isännöi myös kontteja tai paikallista hypervisoria, tarkista, etteivät ne jo sillitä samaan uplinkiin. Kaksi siltaa yhdellä NIC:llä on suunnittelu, ei onnettomuus, jonka haluat löytää muutosikkunan aikana.
Vahvista pakettipolulla, ei pingillä
Tarkista todellinen polku, ei vain tavoitettavuus. Vahvista asiakkaalta, mikä lähdeosoite saapuu kaukaiseen palveluun, ja sitten että vastaus palaa samaa tietä. Tarkista vieraalla tietyn virtauksen edelleenlaskurit ja porttiryhmällä, ettei valitun suunnittelun tarpeiden yli ole otettu käyttöön lisänäkyvyyttä.
Testaa lopuksi vikasuunta. Pysäytä tunneli tai irrota asiakas ja tarkista, ettei liikenne putoa hiljaa reititetylle polulle, jota luulit käyttämättömäksi, sillä juuri se putoaminen tekee sillitetystä suunnittelusta hiljaa tahattoman reitittimen.