Ĉefnodo kaj radiado aŭ plena maŝo: kiu VPN-topologio taŭgas por viaj ejoj

Du filiaj oficejoj parolas unu kun la alia la tutan tagon, kaj la tunelo inter ili faras ĉirkaŭiron tra datencentro en alia regiono. Ĉiu peto pagas por tiu ĉirkaŭiro dufoje, kaj neniu rimarkas ĝin ĝis la dosiera sinkronigo komencas ŝajni malĝusta. Ĝuste tie la demando pri topologio vere komenciĝas: ne per tio, kiu diagramo aspektas pli rezistema, sed per tio, por kiu trafika ŝablono vi pagas. Ambaŭ projektoj funkcias, kaj ili paneas laŭ malsamaj manieroj kun malsamaj kostoj.

Kalkulu la rilatojn inter kunuloj antaŭ ĉio alia

Ĉe N ejoj, plena maŝo bezonas N oble N minus unu, dividite per du, tunelojn; ĉefnodo bezonas N. Ĉe kvin ejoj tio estas dek kontraŭ kvin, kio ankoraŭ sonas reganta. Ĉe dek kvin tio estas 105 kontraŭ dek kvin, kaj la diferenco jam ne estas aritmetika sed kadra.

Ĉiu el tiuj rilatoj portas staton, kiun vi devas posedi. En IPsec tio signifas sekurecan asociiĝon, identecon, ŝlosilon aŭ atestilon, malkovron de mortinta kunulo kaj almenaŭ unu itineron por ĉiu fora prefikso. En WireGuard ĝi signifas publikan ŝlosilon kaj AllowedIPs blokon por ĉiu kunulo, kio estas pli malmultekosta po kunulo sed venas tute sen malkovro: nova ejo estas ĉiuokaze konfigura ŝanĝo ĉe ĉiu ekzistanta.

Lasu la trafikan miksaĵon decidi, ne la desegnaĵon

Se la filia trafiko plejparte estas petoj al centra ERP aŭ dosierklastro, ĉefnodo ne estas kompromiso, ĝi estas la ĝusta formo: la trafiko jam volis iri tien, kaj unu politika punkto estas pli facile revidebla ol maŝo da paraj reguloj. Maŝo meritplas sian kompleksecon, kiam filioj interŝanĝas datumojn unu kun la alia — reproduktado inter du oficejoj, voĉo inter ejoj, komuna CAD-dosierujo, kiun dekduo da inĝenieroj malfermas la tutan tagon.

La maloportunaj kazoj kuŝas en la mezo, kaj ili estas la plimulto. Mezuru antaŭ ol disputi anstataŭ diveni el organiza diagramo.

Legu la tabelon kiel decidan helpilon, ne kiel regulon. Tri el kvar vicoj en unu direkto kutime decidas la projekton; divido signifas hibridon, al kiu la plej multaj maturaj retoj ĉiuokaze alvenas.

Oni devas diri al ĉefnodo, ke ĝi plusendu

Du funkciantaj tuneloj de radiado al ĉefnodo ne kreas radiadan al radiadan aliron. La ĉefnodo bezonas ŝaltitan IP-plusendadon, itineron al ĉiu radiada reto, fajroŝirma regulo, kiu permesas la trairon, kaj ellaboritan revenan vojon; ĉiu radiado bezonas itineron por la prefiksoj de la alia ejo. Sur Linuxa ĉefnodo tio estas net.ipv4.ip_forward=1 plus FORWARD ĉeno, kiu ne silentas forĵetas la paron, kaj ĉe politika IPsec temas pri trafikaj selektiloj, kiuj listigas la foran radiadan subreton ĉe ambaŭ finoj. Ĉe strongSwan la notoj pri plusendado kovras la kernan kaj fajroŝirman flankojn, kiam ĝuste tiu tavolo mankas al vi. Malmultekosta testo estas sendi trafikon de unu radiado al servo ĉe la alia dum vi observas la nombrilojn de la ĉefnodo; regulo, kiu neniam pliiĝas, signifas ke la ordo estas malĝusta, ne la itinero.

Centra politiko ankaŭ estas la utila parto. Oni povas permesi al filioj atingi komunajn servojn sen atingi unu la alian, kaj tiu alira matrico indas esti skribita eksplicite. Mankantaj itineroj estas malbona anstataŭaĵo por regulo, kiun iu povas legi.

Atentu la duonan version: radiado A itinera al radiado B tra la ĉefnodo, la ĉefnodo itinera ambaŭdirekte, kaj la fajroŝirmilo de la ĉefnodo permesas novajn konektojn de A sed ne de B. La unua direkto testiĝas bone kaj la dua pendumas, kio aspektas kiel itinera paneo kaj ne estas.

Projektu la paneon, poste la normalan vojon

Unu sola ĉefnodo estas komuna dependeco kaj traira botelo, kaj la rezerveco estas ĝuste tie, kie ĉefnodaj projektoj kutime eraras. Du ĉefnodoj signifas, ke ĉiu radiado tenas du tunelojn, kaj la reenira vojo devas kongrui kun la elira; kiam ĝi ne kongruas, stata fajroŝirmilo forĵetas la respondojn kaj la simptomo estas konekto, kiu malfermiĝas kaj poste mortas. Pli grandaj enkondukoj solvas tion per itinera protokolo super la tuneloj anstataŭ statikaj prefiksoj, kio estas pli da maŝinaro sed forigas la divenadon. Kion ajn vi elektas, skribu la reeniran vojon apud la elira, ĉar la reenira duono estas tiu, kiun neniu testas.

Maŝo disvastigas tiun riskon: la falo de la ligo de unu ejo ne izolas la aliajn. Ĝi ankaŭ multobligas la lokojn, kie voja elekto povas surprizi vin, kaj aplikaĵaj sesioj ankoraŭ ne postvivas vojan ŝanĝon sen helpo.

Neniu el la du projektoj memtenas TCP-sesion viva dum transiro. Se la aplikaĵo ne povas rekonekti, la topologio ne estas via problemo.

Elektu laŭ kosto de ŝanĝo, poste kontrolu la itinerojn

Komencu per la ĉefnodo, ĉar ĝi estas la pli malmultekosta afero pri kiu erari, kaj aldonu rektajn tunelojn por la paroj, kies trafiko pravigas tion. Tiu hibrido ne estas malsukceso decidi; ĝi estas la projekto, al kiu la plej multaj organizoj konverĝas ene de jaro. Gravas, ke ĉiu rekta ligo havu deklarita kaŭzon kaj posedanton.

Poste kontrolu la du desegnaĵojn anstataŭ unu. Por la normala vojo, traceroute de ĉiu ejo al ĉiu serva prefikso kaj konfirmu, ke la saltoj kongruas kun la diagramo. Por la panea vojo, fermu unu tunelon kaj ripetu, ĉar itinero, kiu funkcias nur dum ĉio estas supre, ne estis projektita, nur agordita.

Konservu ambaŭ desegnaĵojn kun la alira matrico, kaj revizitu ilin kiam ejo aldoniĝas; la kosto, kiun vi administras, estas la kosto de la sekva ŝanĝo, ne la eleganteco de la nuna bildo.