Hub i spoke ili puna mreža: koja VPN topologija odgovara vašim lokacijama
Dva tunela koja rade nisu topologija. Uporedite tranzit, ponašanje pri kvaru i cijenu promjene prije nego što odaberete hub, punu mrežu ili hub s nekoliko direktnih veza.
Dvije podružnice razgovaraju cijeli dan, a tunel između njih ide kroz data centar u drugoj regiji. Svaki zahtjev plaća to skretanje dvaput, i niko to ne primijeti dok sinhronizacija datoteka ne počne izgledati pogrešno. Tu pitanje topologije zaista počinje: ne time koji dijagram izgleda otpornije, nego time za kakav obrazac saobraćaja plaćate. Oba dizajna rade, i otkazuju na različite načine uz različite troškove.
Prvo prebrojte odnose između peerova
Sa N lokacija, puna mreža traži N puta N minus jedan, podijeljeno sa dva, tunela; hub traži N. Na pet lokacija to je deset prema pet, što još zvuči izvodljivo. Na petnaest to je 105 prema petnaest, a razlika više nije aritmetička nego kadrovska.
Svaki od tih odnosa nosi stanje koje morate posjedovati. U IPsecu to znači sigurnosnu asocijaciju, identitet, ključ ili certifikat, otkrivanje mrtvog peera i barem jednu rutu po udaljenom prefiksu. U WireGuardu to znači javni ključ i AllowedIPs blok po peeru, što je jeftinije po peeru ali dolazi potpuno bez otkrivanja: nova lokacija je ionako promjena konfiguracije na svakoj postojećoj.
Neka odluči mješavina saobraćaja, ne crtež
Ako je saobraćaj podružnica uglavnom zahtjevi prema centralnom ERP-u ili klasteru datoteka, hub nije kompromis, to je ispravan oblik: saobraćaj je već htio ići tamo, a jedna tačka politike lakše se revidira od mreže parnih pravila. Puna mreža zaslužuje svoju složenost kada podružnice razmjenjuju podatke međusobno — replikacija između dvije kancelarije, glas između lokacija, dijeljeni CAD koji desetine inženjera otvaraju cijeli dan.
Nezgodni slučajevi leže između i oni su većina. Mjerite prije nego što se prepirete, umjesto da pogađate iz organizacione šeme.
| Signal | Ukazuje na hub | Ukazuje na punu mrežu |
|---|---|---|
| Saobraćaj između podružnica | Povremen, mali | Dominantan, cijeli dan |
| Broj lokacija | Raste, preko deset | Mali i stabilan |
| Tempo promjena | Česta dodavanja i premještanja | Rijedak |
| Tolerancija na kvarove | Drugi hub je priuštiv | Svaka lokacija mora preživjeti sama |
Čitajte tabelu kao odlučujući faktor, ne kao pravilo. Tri od četiri reda u jednom smjeru obično riješe dizajn; podjela znači hibrid, na čemu većina zrelih mreža ionako završi.
Hubu se mora reći da prosljeđuje
Dva tunela spoke-hub koja rade ne stvaraju pristup spoke-spoke. Hubu treba uključeno IP prosljeđivanje, ruta do svake spoke mreže, pravilo firewalla koje dopušta tranzit i izračunat povratni put; svakom spokeu treba ruta za prefikse druge lokacije. Na Linux hubu to je net.ipv4.ip_forward=1 plus FORWARD lanac koji tiho ne odbacuje par, a na IPsecu zasnovanom na politikama to su selektori saobraćaja koji na oba kraja navode udaljenu spoke podmrežu. U strongSwanu napomene o prosljeđivanju pokrivaju stranu kernela i firewalla kada je to sloj koji vam nedostaje. Jeftin test je poslati saobraćaj s jednog spokea na uslugu na drugom dok gledate brojače huba; pravilo koje nikad ne poraste znači da je redoslijed pogrešan, ne ruta.
Centralna politika je također koristan dio. Podružnicama se može dopustiti pristup dijeljenim uslugama bez pristupa jedna drugoj, a tu matricu pristupa vrijedi izričito zapisati. Rute koje nedostaju loša su zamjena za pravilo koje neko može pročitati.
Pazite na polovičnu verziju: spoke A ruta do spokea B ide kroz hub, hub rutira u oba smjera, a firewall huba dopušta nove veze iz A ali ne iz B. Prvi smjer se dobro testira, a drugi visi, što izgleda kao greška rutiranja i nije.
Dizajnirajte kvar, pa onda normalan put
Jedan hub je zajednička zavisnost i tranzitno grlo, a redundancija je mjesto gdje hub dizajni obično pogriješe. Dva huba znače da svaki spoke drži dva tunela, a povratni put se mora slagati s odlaznim; kada ne slaže, stateful firewall odbacuje odgovore i simptom je veza koja se otvori i zatim umre. Veće instalacije to rješavaju protokolom rutiranja preko tunela umjesto statičkih prefiksa, što je više mehanike ali uklanja pogađanje. Šta god odabrali, zapišite povratni put uz odlazni, jer povratnu polovinu nitko ne testira.
Puna mreža raspršuje taj rizik: pad veze jedne lokacije ne izolira ostale. Ona također umnožava mjesta gdje vas odabir puta može iznenaditi, a aplikacijske sesije i dalje ne preživljavaju promjenu puta bez pomoći.
Nijedan dizajn sam ne održava TCP sesiju živom kroz prebacivanje. Ako se aplikacija ne može ponovo povezati, topologija nije vaš problem.
Birajte po cijeni promjene, pa provjerite rute
Počnite s hubom, jer je to jeftinija stvar oko koje možete pogriješiti, i dodajte direktne tunele za parove čiji saobraćaj to opravdava. Taj hibrid nije neuspjeh da se odluči; to je dizajn prema kojem većina organizacija dođe u roku od godinu. Važno je da svaka direktna veza ima naveden razlog i vlasnika.
Zatim provjerite dva crteža umjesto jednog. Za normalan put, traceroute od svake lokacije do svakog prefiksa usluge i potvrdite da skokovi odgovaraju dijagramu. Za put kvara, ugasite jedan tunel i ponovite, jer ruta koja radi samo dok je sve upaljeno nije dizajnirana, samo konfigurisana.
Držite oba crteža uz matricu pristupa i pregledajte ih kada se doda lokacija; trošak kojim upravljate je trošak sljedeće promjene, ne elegancija trenutne slike.