Zvijezda ili puna mreža: koja VPN topologija odgovara vašim lokacijama
Dva tunela koja rade još nisu topologija. Prije nego što odaberete čvorište, punu mrežu ili čvorište s nekoliko izravnih veza, usporedite tranzit, ponašanje pri kvaru i cijenu promjene.
Dvije podružnice razgovaraju jedna s drugom cijeli dan, a tunel između njih obilazi preko data centra u drugoj regiji. Svaki zahtjev plaća taj obilazak dvaput, i nitko to ne primijeti dok sinkronizacija datoteka ne počne djelovati pogrešno. Tu pitanje topologije doista počinje: ne time koja shema izgleda otpornije, već time za koji obrazac prometa plaćate. Oba rješenja rade, i oba zataje na različite načine i po različitoj cijeni.
Prvo prebrojite odnose između čvorova
S N lokacija, puna mreža zahtijeva N puta N minus jedan, podijeljeno s dva, tunela; čvorištu treba N. Na pet lokacija to je deset prema pet, što još zvuči izvedivo. Na petnaest to je 105 prema petnaest, i razlika više nije aritmetička, nego kadrovska.
Svaki od tih odnosa nosi stanje koje morate održavati. U IPsecu to znači sigurnosnu asocijaciju, identitet, ključ ili certifikat, otkrivanje mrtvog čvora i barem jednu rutu po udaljenom prefiksu. U WireGuardu to znači javni ključ i blok AllowedIPs po čvoru; jeftinije po čvoru, ali posve bez otkrivanja: nova lokacija je u svakom slučaju promjena konfiguracije na svim postojećim.
Neka odluči sastav prometa, ne crtež
Ako je promet podružnica uglavnom zahtjevi prema središnjem ERP-u ili klasteru datoteka, čvorište nije kompromis nego ispravan oblik: promet je već htio tamo, a jednu točku politike lakše je revidirati nego mrežu pravila po parovima. Puna mreža zaslužuje svoju složenost kada podružnice međusobno razmjenjuju podatke: replikacija između dva ureda, glas između lokacija, CAD dijeljenje koje desetak inženjera otvara cijeli dan.
Nezgodni slučajevi su u sredini, i oni su većina. Mjerite prije nego što se raspravljate, umjesto da nagađate iz organizacijske sheme.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Čitajte tablicu kao presudu, ne kao pravilo. Tri od četiri retka u jednom smjeru obično rješavaju projekt, a podjela znači hibrid, koji većina zrelih mreža na kraju i koristi.
Čvorištu se mora reći da prosljeđuje
Dva tunela koja rade krak-čvorište ne stvaraju pristup između krakova. Čvorištu treba uključeno IP prosljeđivanje, ruta do svake mreže kraka, pravilo vatrozida koje dopušta tranzit i izračunat povratni put; svakom kraku treba ruta do prefiksa druge lokacije. Na Linux čvorištu to je net.ipv4.ip_forward=1 plus lanac FORWARD koji tiho ne odbacuje par, a u IPsecu zasnovanom na politikama to su selektori prometa koji na oba kraja navode podmrežu udaljenog kraka. strongSwan bilješke o prosljeđivanju pokrivaju stranu jezgre i vatrozida kada je upravo taj sloj ono što vam nedostaje. Jeftin test: pošaljite promet iz jednog kraka prema usluzi na drugom i gledajte brojače čvorišta; pravilo koje nikad ne naraste znači da je pogrešan redoslijed, a ne ruta.
Središnja politika je također koristan dio. Podružnicama se može dopustiti da dosegnu zajedničke usluge bez pristupa jedna drugoj, i tu matricu pristupa vrijedi izričito zapisati. Rute koje nedostaju loša su zamjena za pravilo koje netko može pročitati.
Pazite na napola gotovu verziju: krak A usmjerava prema kraku B kroz čvorište, čvorište usmjerava u oba smjera, a vatrozid čvorišta dopušta nove veze iz A, ali ne iz B. Prvi se smjer dobro testira, drugi visi, što izgleda kao greška usmjeravanja i nije.
Prvo projektirajte kvar, zatim normalan put
Jedno čvorište je zajednička ovisnost i tranzitno grlo, a redundancija je mjesto gdje projekti s čvorištem obično pogriješe. Dva čvorišta znače da svaki krak drži dva tunela, a povratni put mora se slagati s odlaznim; kada se ne slaže, vatrozid sa stanjem odbacuje odgovore, a simptom je veza koja se otvori i zatim umre. Veće instalacije to rješavaju protokolom usmjeravanja preko tunela umjesto statičkih prefiksa, što je više mehanike, ali uklanja nagađanje. Što god odaberete, zapišite povratni put uz odlazni, jer je povratna polovica ona koju nitko ne testira.
Puna mreža raspršuje taj rizik: pad veze jedne lokacije ne izolira ostale. Ali i umnožava mjesta na kojima vas odabir puta može iznenaditi, a sesije aplikacija još uvijek ne preživljavaju promjenu puta bez pomoći.
Nijedno rješenje samo ne održava TCP sesiju živom tijekom prebacivanja. Ako se aplikacija ne može ponovno spojiti, topologija nije vaš problem.
Birajte po cijeni promjene, zatim provjerite rute
Počnite s čvorištem, jer je to jeftinija stvar za pogriješiti, i dodajte izravne tunele za parove čiji promet to opravdava. Taj hibrid nije neuspjeh u odlučivanju; to je projekt na koji većina organizacija stigne unutar godine. Važno je da svaka izravna veza ima naveden razlog i vlasnika.
Zatim provjerite dva crteža umjesto jednog. Za normalan put pokrenite traceroute sa svake lokacije na svaki prefiks usluge i potvrdite da skokovi odgovaraju dijagramu. Za put kvara isključite jedan tunel i ponovite, jer ruta koja radi samo dok je sve podignuto nije projektirana, nego samo konfigurirana.
Čuvajte oba crteža s matricom pristupa i vratite im se kada se doda lokacija; cijena kojom upravljate je cijena sljedeće promjene, ne elegancija trenutne slike.