VPN L2 versus tunel L3: cinci verificări înainte de a punte un sediu

Puntezi un sediu pentru că un instrument insistă că trebuie să fie în aceeași rețea, iar trei săptămâni mai târziu citești jurnalele comutatorului la ora două dimineața. Astfel de intuiție decide mult prea multe legături Ethernet peste IP. Aici contează cu adevărat o singură diferență: dacă circulă cadre întregi de la un capăt la altul sau doar pachete IP. Rulați cele cinci verificări de mai jos în ordine și opriți-vă la prima care eșuează.

Verificați ce pune de fapt aplicația pe fir

Înainte ca vreun nume de produs să intre în discuție, capturați un minut din traficul care trebuie să traverseze legătura: tcpdump -i eth0 -nn -e 'not ip'. Opțiunea -e tipărește antetul nivelului de legătură, iar aceasta este exact partea pe care un tunel rutat o aruncă. Dacă captura rămâne goală, aplicația vorbește IP și un tunel L3 o transportă neschimbat. Dacă apar totuși cadre, notați EtherType, pentru că 0x0806 este ARP, 0x88cc este LLDP, iar o valoare de producător înseamnă de obicei un protocol de descoperire fără alternativă IP. În acel punct o tun interfață obișnuită nu mai este de ajuns.

Repetați captura și pe partea îndepărtată. Un cadru care există doar în interiorul comutatorului virtual al unui singur gazdă nu este motiv să întindeți un domeniu de difuzare peste un WAN.

Verificați dacă descoperirea trebuie să traverseze legătura

Un tunel rutat nu are niciun segment comun, așa că nimic adresat unui grup nu ajunge la celălalt capăt. ARP, difuzările DHCP, mDNS la 224.0.0.251, SSDP și interogările de nume NetBIOS presupun toate o legătură pe care mai multe gazde o aud simultan.

Întrebați de care dintre ele depinde cu adevărat aplicația și dacă există deja un proxy pentru ele. Retransmisia DHCP, reflexia mDNS și intrările ARP statice elimină fiecare câte o dependență, iar fiecare este încă un serviciu de rulat și monitorizat. Când rămân două sau trei, puntea este răspunsul onest.

Verificați cât vă costă antetul suplimentar

Cadrele au nevoie de un loc unde să locuiască, așa că tot ce trimiteți primește un al doilea stiv de antete în jur. Într-un overlay VXLAN asta înseamnă un antet IP exterior, un antet UDP și un antet VXLAN de 8 octeți, ceea ce împinge o încărcătură completă de 1,500 octeți dincolo de MTU de cale al unei legături internet obișnuite de 1,500 octeți. OpenVPN în modul tap adaugă propriul overhead în aceeași direcție. Fără un MTU mai mic pe partea internă obțineți o legătură care răspunde la ping și se blochează la primul transfer mare.

Factura nu se oprește la octeții de antet. Difuzarea și multicastul pe care comutatorul le trată în hardware merg acum prin WAN, iar fiecare sediu punte moștenește același plan de adrese, același interval DHCP și același comportament la adrese duplicate. Asta face legătura mult mai greu de auditat decât un bazin rutat cu un prefix pe sediu.

Faceți calculele înainte de a alege. Un segment aglomerat replicat la trei sedii poate muta mai mult trafic de difuzare decât transferurile de fișiere pentru care a fost construit.

Verificați ce tip de VPN L2 vi se oferă

Termenul în sine este ambiguu, iar ambiguitatea decide cine vă transportă traficul. Uneori descrie încărcătura: cadre Ethernet în IP, trimise prin internet ca orice alt tunel, cum fac VXLAN, ZeroTier și modul tap al OpenVPN. Uneori descrie un serviciu cumpărat: un circuit Ethernet de operator sau un pseudocablu MPLS care unește două sedii într-o singură rețea a unui furnizor.

Ambele vă dau un segment, așa că aplicația nu le poate distinge, dar diferența operațională este mare. Un overlay vă lasă responsabilitatea pentru MTU, criptare și calea de dedesubt. Un serviciu de operator preia acestea și le facturează, și nu vă va ruta cadrele prin internetul public deloc. Pe care îl vreți depinde de faptul dacă cele două sedii împart un operator sau doar o companie.

Verificați soluția mai ieftină înainte de a punte

Majoritatea cererilor pentru o legătură punte vin dintr-o singură căutare stricată, nu dintr-un protocol care chiar are nevoie de cadre. Treceți mai întâi resolverul și domeniul de căutare prin tunelul rutat: dhcp-option DNS 10.8.0.1 împreună cu dhcp-option DOMAIN internal.example într-o configurație de server OpenVPN rezolvă un număr surprinzător dintre ele. Un redirector local pe partea îndepărtată face aceeași treabă fără să mute niciun trafic de difuzare.

Dacă un instrument vechi încă eșuează, puneți-l în spatele unui proxy sau al unui gazdă de salt în segmentul de destinație. Un singur redirector TCP este mai ieftin de operat decât un WAN punte.

Închideți decizia în ordine: traficul poartă un EtherType care nu este IP, descoperirea trebuie să traverseze, MTU poate absorbi antetele suplimentare, un circuit de furnizor este într-adevăr disponibil și soluția rutată a eșuat dintr-un motiv pe care îl puteți numi? Un nu la orice pas încheie dezbaterea în favoarea tunelului pe care îl aveți deja. Arhivați captura și lista de EtherType împreună cu registrul de modificări, pentru că următoarea persoană va pune aceeași întrebare și nu va vrea să repete măsurătoarea.