VPN de convidat a ESXi: encaminament o pont, decidiu abans del grup de ports
Un TUN encaminat necessita rutes de retorn; un TAP en pont necessita abast de capa 2 i una política de grup de ports més àmplia. Fixeu el paper abans d'ampliar el mode promiscu.
Encamineu els paquets o amplieu el domini Ethernet: el canvi del grup de ports ve després d'aquesta tria. Des d'una aplicació amb una adreça privada els resultats poden semblar idèntics, mentre que els requisits de l'hipervisor no s'assemblen gens. Per això primer s'amplia el grup de ports i la pregunta de disseny es respon després, normalment després d'una tempesta de broadcast. Feu aquestes comprovacions en ordre i atureu-vos mentre el requisit encara sigui vague, perquè cap paràmetre del grup de ports arregla un disseny que mai no s'ha triat.
La decisió pertany al propietari del servei; la configuració de l'hipervisor l'ha d'implementar, no determinar-la per accident.
Comproveu què necessita realment l'extrem remot
Llisteu els serveis a què han d'arribar els clients remots i els protocols que fan servir. Si la llista és un grapat de serveis TCP sobre prefixos coneguts, l'encaminament ja ho cobreix. Si alguna cosa necessita de debò adjacència de capa 2 — descobriment dependent de broadcast, protocols que no són IP, un dispositiu que no accepta una passarel·la — l'encaminament no ho pot imitar i cal dir-ho aviat. Sigueu honestos amb les entrades no IP d'aquesta llista, perquè és on un disseny encaminat falla en silenci una setmana després.
Després comproveu el pool de clients. Un disseny encaminat necessita un rang d'adreces i una ruta de retorn explícita a l'extrem remot; un disseny en pont necessita que el domini Ethernet ampliat posseeixi l'assignació d'adreces i l'aïllament. Triïs el que triïs, algú fora d'aquesta VM ho ha d'acceptar.
Què demana cada disseny a la xarxa virtual
Els dos dissenys difereixen en què ha de tolerar la xarxa virtual, i la taula és la manera més curta de veure-ho:
| Disseny | Paper al costat del convidat | Què ha d'absorbir la xarxa virtual | Mode de fallada si trieu malament |
|---|---|---|---|
| TUN encaminat | Encaminador entre prefixos separats | Un pool de clients encaminat més rutes de retorn a l'extrem remot | Els clients arriben a la passarel·la i mai no arriben al servei que hi ha darrere |
| TAP en pont | Pont de capa 2 per als clients que s'hi uneixen | Identitats Ethernet addicionals, trànsit de broadcast i regles VLAN | El vSwitch descarta trames, o el disseny necessita un mode promiscu que ningú no ha aprovat |
L'encaminament manté el domini de broadcast on és i us dona un lloc natural per limitar quins serveis creuen la passarel·la. El pont mou la frontera: els clients esdevenen participants del domini Ethernet ampliat, i l'assignació d'adreces, l'aïllament i qualsevol política de capa 2 ara els afecten. Escriviu la fila triada al registre de canvis. Una frase com «TUN encaminat, pool de clients 10.90.0.0/24, ruta de retorn al nucli» evita que el següent enginyer torni a discutir el disseny des dels paràmetres del grup de ports.
Qui ha de poder veure les trames de qui
Feu una pregunta al propietari de la plataforma abans de tocar el grup de ports: el disseny requereix que aquesta VM rebi trames adreçades a altres participants? Si la resposta és no, res d'aquesta secció no s'aplica, perquè un TUN encaminat mai no necessita aquesta visibilitat. Si la resposta és sí, la guia de Broadcom sobre el mode promiscu és la lectura que importa: exposa quant més del vSwitch pot veure la VM i recomana confinar aquesta política a un sol grup de ports.
Tracteu-ho com una comprovació de requisit, no com un permís. Activeu el paràmetre per a un adjunt dedicat quan la necessitat de pont estigui escrita, i deixeu-lo desactivat a tota la resta. Un trunk VLAN ampli copiat d'un altre exemple de pont és la part que ningú no recorda treure, i un disseny d'una sola VLAN ha de romandre d'una sola VLAN.
Registreu quin grup de ports va canviar i per què, al mateix lloc on vau escriure la fila de disseny. Aquesta parella és el que fa possible la propera auditoria.
Manteniu explícits els objectes del convidat
Dins de Linux, la pertinença al pont i la propietat de l'adreça són objectes separats, i barrejar-los causa l'estat confús de mig funcionament. Assigneu adreces a la interfície del pont o al túnel encaminat, no als dos costats del mateix camí, i manteniu els ports membres sense configuració IP.
Eviteu posar una subxarxa independentment en un TUN encaminat i en una interfície Ethernet no relacionada. Aquesta configuració produeix dos camins al mateix prefix, respostes asimètriques i un fil de suport sobre flapping que no esmenta cap dels dos camins. Si el convidat també allotja contenidors o un hipervisor local, comproveu que ja no estiguin fent pont cap al mateix uplink. Dos ponts en una NIC són un disseny, no un accident que vulgueu descobrir durant una finestra de canvi.
Confirmeu amb un camí de paquet, no amb un ping
Verifiqueu el camí real, no només l'abast. Des d'un client, confirmeu quina adreça d'origen arriba al servei remot, i després que la resposta torna pel mateix camí. Al convidat, mireu els comptadors de reenviament per al flux concret, i al grup de ports confirmeu que no s'ha activat cap visibilitat addicional més enllà de la que necessita el disseny triat.
Finalment, proveu la direcció de fallada. Atureu el túnel o desconnecteu el client i comproveu que el trànsit no cau en silenci cap a un camí encaminat que creíeu no utilitzat, perquè aquesta caiguda és com un disseny en pont es converteix en silenci en un encaminador involuntari.