VPN invitat pe ESXi: rutare sau punte — decideți înainte de grupul de porturi
Un TUN rutat are nevoie de rute de întoarcere; un TAP punte are nevoie de acces la stratul 2 și de o politică de grup de porturi mai largă. Stabiliți rolul înainte de a extinde modul promiscuu.
Rutați pachetele sau extindeți domeniul Ethernet: modificarea grupului de porturi urmează acelei alegeri. Din perspectiva unei aplicații cu adresă privată rezultatele pot părea identice, în timp ce cerințele hipervizorului nu seamănă deloc. De aceea grupul de porturi este extins primul, iar întrebarea de proiectare primește răspuns al doilea, de obicei după o furtună de broadcast. Parcurgeți aceste verificări în ordine și opriți-vă cât timp cerința este încă neclară, fiindcă nicio setare a grupului de porturi nu repară un proiect care nu a fost niciodată ales.
Decizia aparține proprietarului serviciului; configurația hipervizorului trebuie să o implementeze, nu să o determine din întâmplare.
Verificați de ce are nevoie cu adevărat capătul îndepărtat
Enumerați serviciile la care clienții de la distanță trebuie să ajungă și protocoalele pe care le folosesc. Dacă lista este o mână de servicii TCP pe prefixe cunoscute, rutarea acoperă. Dacă ceva are într-adevăr nevoie de vecinătate de stratul 2 — descoperire dependentă de broadcast, protocoale non-IP, un dispozitiv care nu acceptă o poartă — rutarea nu poate imita și trebuie spus devreme. Fiți onești cu privire la intrările non-IP din listă, pentru că acolo un proiect rutat eșuează în tăcere o săptămână mai târziu.
Apoi verificați grupul de clienți. Un proiect rutat are nevoie de un interval de adrese și de o rută de întoarcere explicită la capătul îndepărtat; un proiect punte are nevoie ca domeniul Ethernet extins să dețină alocarea adreselor și izolarea. Orice ați alege, cineva din afara acestui VM trebuie să fie de acord.
Ce cere fiecare proiect rețelei virtuale
Cele două proiecte diferă în ce trebuie să tolereze rețeaua virtuală, iar tabelul este cea mai scurtă cale de a vedea asta:
| Proiect | Rolul pe partea de invitat | Ce trebuie să acomodeze rețeaua virtuală | Modul de eșec dacă alegeți greșit |
|---|---|---|---|
| TUN rutat | Router între prefixe separate | Un grup de clienți rutat plus căi de întoarcere la capătul îndepărtat | Clienții ajung la poartă și nu ajung niciodată la serviciul din spatele ei |
| TAP punte | Punte de stratul 2 pentru clienții care se alătură | Identități Ethernet suplimentare, trafic broadcast și reguli VLAN | vSwitch-ul aruncă cadrele, sau proiectul cere un mod promiscuu pe care nimeni nu l-a aprobat |
Rutarea lasă domeniul de broadcast acolo unde este și oferă un loc natural pentru a limita ce servicii traversează poarta. Puntea mută granița: clienții devin participanți ai domeniului Ethernet extins, iar alocarea adreselor, izolarea și orice politică de stratul 2 li se aplică acum. Scrieți rândul ales în registrul de modificări. O frază precum «TUN rutat, grup de clienți 10.90.0.0/24, rută de întoarcere pe nucleu» împiedică următorul inginer să redeschidă dezbaterea despre proiect pornind de la setările grupului de porturi.
Cine ar trebui să poată vedea cadrele cui
Puneți o întrebare proprietarului platformei înainte de a atinge grupul de porturi: proiectul cere ca acest VM să primească cadre adresate altor participanți? Dacă răspunsul este nu, nimic din această secțiune nu se aplică, fiindcă un TUN rutat nu are niciodată nevoie de acea vizibilitate. Dacă răspunsul este da, ghidul Broadcom despre modul promiscuu este lectura care contează: explică cât de mult din vSwitch vede VM-ul și recomandă limitarea acelei politici la un singur grup de porturi.
Tratați asta ca o verificare a cerinței, nu ca o permisiune. Activați setarea pentru o singură conexiune dedicată atunci când nevoia de punte este scrisă, și lăsați-o oprită peste tot altundeva. Un trunk VLAN larg copiat din alt exemplu de punte este partea pe care nimeni nu-și amintește să o elimine, iar un proiect cu un singur VLAN ar trebui să rămână cu un singur VLAN.
Înregistrați care grup de porturi s-a schimbat și de ce, în același loc unde ați scris rândul proiectului. Acea pereche face posibil auditul următor.
Păstrați obiectele invitatului explicite
În Linux, apartenența la punte și proprietatea adresei sunt obiecte separate, iar amestecarea lor produce confuzul stare pe jumătate funcțională. Atribuiți adrese interfeței punții sau tunelului rutat, nu ambelor părți ale aceleiași căi, și păstrați porturile membre fără configurație IP.
Evitați să puneți o subrețea în mod independent pe un TUN rutat și pe o interfață Ethernet necorelată. Acea configurație produce două căi către același prefix, răspunsuri asimetrice și un fir de suport despre flapping care nu menționează niciuna dintre căi. Dacă invitatul găzduiește și containere sau un hipervizor local, verificați că nu fac deja punte către același uplink. Două punți pe o singură NIC sunt un proiect, nu un accident pe care vreți să îl descoperiți într-o fereastră de modificare.
Confirmați cu o cale de pachet, nu cu un ping
Verificați calea reală, nu doar accesibilitatea. De la un client, confirmați ce adresă sursă ajunge la serviciul îndepărtat, apoi că răspunsul se întoarce pe aceeași cale. Pe invitat, verificați contoarele de redirecționare pentru fluxul concret, iar pe grupul de porturi confirmați că nu s-a activat vizibilitate suplimentară peste ce cere proiectul ales.
În final, testați direcția de eșec. Opriți tunelul sau deconectați clientul și verificați că traficul nu cade în tăcere pe o cale rutată pe care o credeați nefolosită, fiindcă acea cădere este felul în care un proiect punte devine în tăcere un router nedorit.