Treba li dva lokaliteta imati iste VLAN ID-ove za VPN između lokaliteta?
Isti VLAN ID-ovi ne mogu popraviti rutirani VPN između lokaliteta: tunel prenosi IP prefikse, pa plan adresa i selektori odlučuju o dostupnosti, a ne oznake na prekidaču.
Isti VLAN brojevi u dva ureda djeluju kao da bi trebali pomoći tunelu između lokaliteta, a ne mijenjaju ništa od onoga što tunel prenosi. VLAN ID označava Ethernet broadcast domenu unutar jedne zgrade; tunel prosljeđuje IP pakete između pristupnika. Dva lokaliteta mogu koristiti potpuno različito VLAN numeriranje i ipak rutirati jedan prema drugome, a dva lokaliteta mogu koristiti isto VLAN numeriranje i ipak ne moći doći jedan do drugoga. Varijabla koja odlučuje o dostupnosti je plan adresa.
Mit: isti VLAN ID-ovi na oba kraja
Uvjerenje dolazi s razumnog mjesta. Unutar jedne zgrade dva porta u istom VLAN-u mogu razgovarati, a dva porta u različitim VLAN-ovima ne mogu, pa VLAN broj izgleda kao ono što daje povezanost. Kroz rutirani tunel nema zajedničkog Ethernet segmenta koji bi oznaka opisala, a pristupnici nikada ne razmjenjuju VLAN oznake.
Tunelu je potreban par adresnih raspona koji se ne preklapaju i politika koja dopušta promet između njih. Promijenite VLAN u bilo kojem uredu i tunel nastavlja raditi, jer ništa u konfiguraciji tunela nije na njega upućivalo. To je test koji rješava raspravu: prenumerirajte VLAN, ostavite adrese na miru i gledajte hoće li tunel ostati aktivan.
Obrnuti test jednako je informativan. Dajte obama uredima istu podmrežu i nikakva količina podudarnih VLAN brojeva neće učiniti adresu nedvosmislenom.
Što tunel zapravo prenosi
IPsec štiti IP pakete prema politici izraženoj u adresama, protokolima i portovima. IPsec arhitektura opisuje te selektore na IP sloju, koji je nekoliko slojeva iznad svega što opisuje oznaka prekidača. Kad paket uđe u tunel, već je napustio VLAN; oznaku je potrošio lokalni prekidač.
Dizajni zasnovani na politici i na rutama razlikuju se po tome kako biraju tunel, a ne po tome što mogu prenijeti. Politici zasnovan peer uparuje selektore prometa i šalje odgovarajuće pakete u tunel. Rutama zasnovan peer rutira promet na sučelju tunela i prepušta odluku tablici usmjeravanja. Oba i dalje pregovaraju opseg zaštite, pa ruta koja pokazuje na tunel ne proširuje ono što su peerovi pristali štititi.
Ta razlika objašnjava čest polovični neuspjeh: ruta postoji, paketi ulaze u tunel, a suprotna strana ih odbacuje jer pregovarani selektori nikada nisu uključivali taj prefiks. Čitanje instaliranih politika pokazuje koji je opseg zapravo stupio na snagu.
ip xfrm policy
ip route show
swanctl --list-sas
Preklapanje koje zaista lomi
Dva ureda s različitim podmrežama rutiraju čisto kroz tunel i njihovi VLAN brojevi su nevažni. Dva ureda s istom podmrežom ne, jer zahtjev za zadanu adresu ima dva moguća značenja a tablica usmjeravanja može odabrati samo jedno. Prenumeriranje jednog lokaliteta je čisto rješenje i obično je jeftinije od alternativa kada se uračunaju promjene DNS-a i vatrozida.
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
Kada je prenumeriranje nemoguće, namjeran dizajn prevođenja može svakoj strani predstaviti različite poglede na adrese. To znači preslikavanje jedan-na-jedan, podudarne selektore, DNS unose koji odražavaju prevedeni pogled i povratno rutiranje koje preživljava prepisivanje. To je podržan dizajn sa stvarnim operativnim troškom i nije ono što čini promjena VLAN ID-a.
Isti VLAN brojevi na oba kraja ponekad su slučajnost zajedničkog predloška, a tretiranje te slučajnosti kao uzroka funkcionalnog tunela vodi pogrešnoj promjeni kada se nešto kasnije pokvari.
Jedan posao po sloju, zapisan
Lokalni prekidač odlučuje koji portovi dijele broadcast domenu, a njegovo VLAN numeriranje je lokalno knjigovodstvo koje nijedan drugi lokalitet ne treba znati. Pristupnik provjerava identitet peera i provodi pregovarani opseg zaštite. Tablica usmjeravanja odlučuje kamo dešifrirani paket ide dalje, a politika pristupa odlučuje je li tom paketu uopće trebalo dopustiti prolaz.
Upravo razdvajanje tih poslova čini promjene sigurnima. Prenumeriranje VLAN-a u jednom uredu dira lokalni prekidač, DHCP raspon i moguće zonu vatrozida, a ne dira tunel. Promjena prefiksa dira selektore tunela, rute na obje strane i politiku pristupa, a ne dira oznake prekidača.
Povratne rute, privatni DNS i zahtjevi za identitet aplikacije opet su odvojeni poslovi i nijedan od njih ne dolazi kopiranjem VLAN broja s drugog lokaliteta. Projektni dokument koji navodi dostupne prefikse i dopuštene usluge preživljava zamjenu prekidača; onaj koji navodi VLAN brojeve ne.
Potvrdite lokalnu sliku bridge alatima prije nego pretpostavite da oznaka stiže do tunela.
bridge vlan show
ip -br addr
ip route get 10.62.0.20
Kada je proširenje layer-2 stvarni zahtjev
Neki dizajni zaista trebaju Ethernet ponašanje između lokaliteta: naslijeđena aplikacija koja se oslanja na broadcast otkrivanje, migracija koja mora zadržati adresu dok se stroj premješta, ili protokol koji ugrađuje layer-2 pretpostavke. Takvi slučajevi traže overlay ili premosnu uslugu koja nosi okvire, a tada članstvo u VLAN-u, sprječavanje petlji i rukovanje otkazima postaju pitanja od kraja do kraja.
To je mnogo veći domen otkaza i treba biti namjeran izbor, a ne slučajni rezultat pokušaja da se osposobi dijeljenje datoteka. Obični datotečni poslužitelj, baza podataka ili web aplikacija trebaju ovlašten IP put i bit će sretniji bez rastegnutog broadcast domena ispod sebe.
Zapišite VPN ugovor kao dostupne prefikse plus dopuštene usluge i zabilježite VLAN oznaku samo tamo gdje je potrebna lokalnim operacijama. Svaki ured tada može prenumerirati svoje preklapanje a da svaku promjenu ne pretvori u redizajn tunela.