Au nevoie două locații de aceleași VLAN ID pentru un VPN de locație?

Aceleași numere VLAN în două birouri par să ar trebui să ajute un tunel între locații, și nu schimbă nimic din ce transportă tunelul. Un VLAN ID marchează un domeniu de difuzare Ethernet în interiorul unei clădiri; tunelul transmite pachete IP între gateway-uri. Două locații pot folosi o numerotare VLAN complet diferită și totuși să ruteze una spre cealaltă, iar două locații pot folosi aceeași numerotare VLAN și totuși să nu se poată atinge. Variabila care decide accesibilitatea este planul de adrese.

Mitul: aceleași VLAN ID la ambele capete

Convingerea vine dintr-un loc rezonabil. În interiorul unei clădiri, două porturi din același VLAN pot vorbi, iar două porturi din VLAN-uri diferite nu pot, așa că numărul VLAN pare lucrul care acordă conectivitate. Printr-un tunel rutat nu există niciun segment Ethernet partajat pe care eticheta să îl descrie, iar gateway-urile nu schimbă niciodată etichete VLAN.

Ceea ce are nevoie tunelul este o pereche de intervale de adrese care nu se suprapun și o politică ce permite traficul dintre ele. Schimbați VLAN-ul în orice birou și tunelul continuă să funcționeze, pentru că nimic din configurația tunelului nu făcea referire la el. Acesta este testul care închide dezbaterea: renumerotați un VLAN, lăsați adresele neatinse și urmăriți dacă tunelul rezistă.

Testul invers este la fel de instructiv. Dați ambelor birouri aceeași subrețea și nicio cantitate de numere VLAN identice nu va face o adresă lipsită de ambiguitate.

Ce transportă de fapt tunelul

IPsec protejează pachetele IP conform unei politici exprimate în adrese, protocoale și porturi. Arhitectura IPsec descrie acești selectori la nivelul IP, care se află cu mai multe straturi deasupra a tot ceea ce descrie o etichetă de comutator. Când un pachet intră în tunel, a părăsit deja VLAN-ul; eticheta a fost consumată de comutatorul local.

Proiectele bazate pe politică și cele bazate pe rute diferă prin modul în care aleg tunelul, nu prin ceea ce pot transporta. Un partener bazat pe politică potrivește selectorii de trafic și trimite pachetele potrivite în tunel. Un partener bazat pe rute rută traficul pe o interfață de tunel și lasă decizia tabelului de rutare. Ambele negociază în continuare un domeniu de protecție, așa că o rută care indică tunelul nu extinde ceea ce partenerii au convenit să protejeze.

Această distincție explică un eșec parțial frecvent: ruta există, pachetele intră în tunel, iar partea îndepărtată le aruncă pentru că selectorii negociați nu au inclus niciodată acel prefix. Citirea politicilor instalate arată ce domeniu a intrat efectiv în vigoare.

ip xfrm policy
ip route show
swanctl --list-sas

Suprapunerea care chiar rupe

Două birouri cu subrețele diferite rutează curat printr-un tunel, iar numerele lor VLAN sunt irelevante. Două birouri cu aceeași subrețea nu, pentru că o cerere pentru o adresă dată are două sensuri posibile și tabelul de rutare poate alege doar unul. Renumerotarea unei locații este soluția curată și este de obicei mai ieftină decât alternativele după ce se socotesc modificările DNS și de firewall.

Când renumerotarea este imposibilă, un proiect de traducere deliberat poate prezenta vederi de adrese distincte fiecărei părți. Asta înseamnă mapare unu-la-unu, selectori potriviți, intrări DNS care reflectă vederea tradusă și rutare de retur care supraviețuiește rescrierii. Este un proiect susținut cu un cost operațional real și nu este ceea ce face schimbarea unui VLAN ID.

Aceleași numere VLAN la ambele capete sunt uneori o coincidență a unui șablon partajat, iar tratarea acelei coincidențe drept cauză a unui tunel funcțional duce la schimbarea greșită când ceva se strică mai târziu.

O sarcină pe strat, scrisă

Comutatorul local decide ce porturi împart un domeniu de difuzare, iar numerotarea sa VLAN este contabilitate locală pe care nicio altă locație nu trebuie să o cunoască. Gateway-ul autentifică partenerul și aplică domeniul de protecție negociat. Tabelul de rutare decide unde merge în continuare un pachet decriptat, iar politica de acces decide dacă acel pachet ar fi trebuit permis.

Păstrarea acestor sarcini separate este ceea ce face schimbările sigure. O renumerotare VLAN într-un birou atinge comutatorul local, intervalul DHCP și poate o zonă de firewall, și nu atinge tunelul. O schimbare de prefix atinge selectorii tunelului, rutele din ambele părți și politica de acces, și nu atinge etichetele comutatorului.

Rutele de retur, DNS-ul privat și cerințele de identitate ale aplicației sunt din nou sarcini separate și niciuna nu apare copiind un număr VLAN de la cealaltă locație. Un document de proiectare care listează prefixele accesibile și serviciile permise supraviețuiește unei înlocuiri de comutator; unul care listează numere VLAN nu.

Confirmați imaginea locală cu instrumentele bridge înainte de a presupune că o etichetă ajunge la tunel.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Când extinderea layer-2 este cerința reală

Unele proiecte au nevoie cu adevărat de comportament Ethernet între locații: o aplicație veche care se bazează pe descoperirea prin difuzare, o migrare care trebuie să păstreze o adresă în timp ce o mașină se mută, sau un protocol care încorporează presupuneri layer-2. Asemenea cazuri cer un overlay sau un serviciu punte care transportă cadrele, iar atunci apartenența la VLAN, prevenirea buclelor și tratarea defecțiunilor devin chestiuni de la un capăt la altul.

Este un domeniu de defectare mult mai mare și ar trebui să fie o alegere deliberată, nu rezultatul accidental al încercării de a pune în funcțiune partajarea fișierelor. Un server de fișiere, o bază de date sau o aplicație web obișnuite au nevoie de o cale IP autorizată și vor fi mai fericite fără un domeniu de difuzare întins dedesubt.

Scrieți contractul VPN ca prefixe accesibile plus servicii permise și înregistrați eticheta VLAN doar acolo unde operațiunile locale au nevoie de ea. Atunci fiecare birou își poate renumerota propria comutare fără a transforma fiecare schimbare într-o reproiectare a tunelului.