Hub-en-spoke of folslein mesh: hokker VPN-topology past by jo lokaasjes
Twa wurkjende tunnels binne noch gjin topology. Ferlykje transit, gedrach by falen en de kosten fan feroaring foardat jo in hub, in mesh of in hub mei in pear direkte keppelings kieze.
Twa filialen prate de hiele dei mei elkoar, en de tunnel tusken harren makket in omwei troch in datacenter yn in oare regio. Elk fersyk betellet dy omwei twaris, en nimmen merkt it oant de bestânsynkronisaasje nuver begjint te fielen. Dêr begjint de topologyske fraach echt: net by hokker diagram oft der fearkrêftiger útsjocht, mar by hokker ferkearspatroan oft jo foar betelje. Beide ûntwerpen wurkje, en se falle op ferskillende manieren mei ferskillende kosten.
Tel earst de peer-relaasjes
By N lokaasjes hat in folslein mesh N kear N min ien, dield troch twa, tunnels nedich; in hub hat N nedich. By fiif lokaasjes is dat tsien tsjin fiif, wat noch hanthavenber klinkt. By fyftjin is it 105 tsjin fyftjin, en it ferskil is gjin rekkenjen mear, mar personiel.
Elk fan dy relaasjes draacht steat dy't jo besitte moatte. Yn IPsec betsjut dat in befeiligingsassosjaasje, in identiteit, in kaai as sertifikaat, deteksje fan deade peers en teminsten ien rûte per ôfstân prefiks. Yn WireGuard betsjut it in iepenbiere kaai en in AllowedIPs blok per peer, wat per peer goedkeaper is, mar hielendal sûnder ûntdekking komt: in nij lokaasje is hoe dan ek in konfiguraasjeferoaring op elk besteand ien.
Lit de ferkearsmingeling beslisse, net de tekening
As it ferkear fan filialen benammen fersiken nei in sintrale ERP of in bestânskluster is, is in hub gjin kompromis, it is de juste foarm: it ferkear woe al dêr hinne, en ien beliedspunt is makliker te auditearjen as in mesh fan peargewiis regels. In mesh fertsjinnet syn kompleksiteit as filialen gegevens mei elkoar útwikselje — replikaasje tusken twa kantoaren, stim tusken lokaasjes, in dielde CAD-map dy't in dozyn yngenieurs de hiele dei iepenje.
De ûngemaklike gefallen lizze der tuskenyn, en se binne de mearderheid. Mjitfoar jo diskusjearje, ynstee fan te rieden út in organisaasjeskema.
| Sinjaal | Wiist op in hub | Wiist op in mesh |
|---|---|---|
| Ferkear tusken filialen | Somtiden, lyts | Oerhearskjend, de hiele dei |
| Oantal lokaasjes | Groeit, foarby tsien | Lyts en stabyl |
| Feroaringstempo | Gauris tafoegings en ferhuzings | Seldsum |
| Fouttolerânsje | In twadde hub is betelber | Elk lokaasje moat allinnich oerlibje |
Lês de tabel as in beslisser, net as in regel. Trije fan fjouwer rigen yn ien rjochting beslist it ûntwerp meastentiids; in splitsing betsjut in hybride, dêr't de measte folwoeksen netwurken hoe dan ek op útdwale.
In hub moat sein wurde dat er trochstjoert
Twa wurkjende spoke-nei-hub-tunnels meitsje gjin tagong spoke-nei-spoke. De hub hat IP-trochstjoering ynskeakele nedich, in rûte nei elk spoke-netwurk, in firewallregel dy't de trochgong tastiet en it weromwei útreeden; elk spoke hat in rûte nedich foar de prefiksen fan it oare lokaasje. Op in Linux-hub is dat net.ipv4.ip_forward=1 plus FORWARD in keatling dy't it pear net stilwei falle lit, en op beliedsbasearre IPsec binne it ferkearsselektors dy't it fiere spoke-subnet oan beide kanten listigje. By strongSwan de notysjes oer trochstjoeren dekke de kernel- en firewallkant as dat de laach is dy't jo misse. In goedkeape test is ferkear fan ien spoke nei in tsjinst op 'e oare stjoere wylst jo de tellers fan 'e hub besjogge; in regel dy't nea omheech giet betsjut dat de folchoarder ferkeard is, net de rûte.
Sintraal belied is ek it nijsgjirrige part. Filialen kinne tagong krije ta dielde tsjinsten sûnder ta elkoar te kommen, en dy tagongsmatriks is it wurdich eksplisyt op te skriuwen. Ûntbrekkende rûtes binne in min ferfanging foar in regel dy't immen lêze kin.
Pas op foar de healôfferme: spoke A rûtelet nei spoke B fia de hub, de hub rûtelet beide kanten, en de firewall fan 'e hub lit nije ferbiningen fan A ta mar net fan B. De earste rjochting testet goed en de twadde hinget, wat op in rûtefout liket en it net is.
Untwerp earst it falen, dan it normale paad
In inkele hub is in dielde ôfhinklikens en in trochgongsknelpunt, en oerstalligens is wêr't hub-ûntwerpen meastentiids misgeane. Twa hubs betsjutte dat elk spoke twa tunnels hâldt, en it weromwei moat oerienkomme mei it útgeande; as it dat net docht, smyt in stateful firewall de antwurden fuort en it symptoom is in ferbining dy't iepengiet en dan stjert. Gruttere útrôljen lossen dit op mei in rûteprotokol oer de tunnels ynstee fan statyske prefiksen, wat mear masines is mar it rieden fuorthellet. Wat jo ek kieze, skriuw it weromwei neist it útgeande, want de weromhelte is dejinge dy't nimmen testet.
In mesh ferspriedt dat risiko: it keppeling fan ien lokaasje dy't delgiet isolearret de oaren net. It fermannichfâldiget ek de plakken dêr't paadkarje jo ferrasse kin, en applikaasjesesjes oerlibje noch altyd gjin paadferoaring sûnder help.
Gjin fan beide ûntwerpen hâldt in TCP-sesje by in failover libben út himsels. As de applikaasje net wer ferbine kin, is topology net jo probleem.
Kies op kosten fan feroaring, en ferifiearje dan de rûtes
Begjin by de hub, want dat is it goedkeapere ding om ferkeard oer te wêzen, en foegje direkte tunnels ta foar de pearen waans ferkear it rjochtfeardiget. Dy hybride is gjin mislearring om te besluten; it is it ûntwerp dêr't de measte organisaasjes binnen in jier op gearkomme. Wat wichtich is, is dat elke direkte keppeling in neamde reden en in eigner hat.
Ferifiearje dan de twa tekeningen ynstee fan ien. Foar it normale paad, traceroute fan elk lokaasje nei elk tsjinstprefiks en befêstigje dat de hops by it diagram passe. Foar it falpaad, slút ien tunnel en werhelje it, want in rûte dy't allinnich wurket wylst alles oan is, is net ûntwurpen, allinnich konfigurearre.
Hâld beide tekeningen by de tagongsmatriks, en besjoch se wer as der in lokaasje bykomt; de kosten dy't jo beheare binne de kosten fan 'e folgjende feroaring, net de elegance fan it hjoeddeiske byld.