Planu privatajn VPN-adresajn areojn antaŭ ol retejoj kolizias

Du retejoj, kiuj ambaŭ uzas 192.168.1.0/24, povas ĉiu atingi la interreton kaj tamen ne atingi unu la alian. La enirejo ne raportas eraron; ĝi instalas unu itineron por tiu prefikso kaj sendas ĉiun paketon al tiu kunulo, kiu postulis ĝin unue. Nenio en la manpremo, la ĉifra listo aŭ la interfaca metriko diras, kiu kunulo malpravas. Adresa planado estas la parto de la dezajno, kiu solvas tion antaŭ ol iu ajn konektiĝas.

Inventaru ĉiun spacon, kiu devas esti atingebla

Notu la areojn, kiujn oni devas enkursigi, ne nur tiujn, kiujn vi agordas. Tio signifas retejajn LAN-ojn, VPN-klientajn basenojn, nubajn subretojn, administrajn kaj eksterbendajn retojn, laboratoriajn segmentojn kaj la retojn, de kiuj uzantoj kutime konektiĝas hejme. Konsumanta enkursigilo, kiu venas kiel 192.168.1.0/24, ne estas hipoteza, kaj la sama prefikso aperas en hoteloj kaj konferencaj lokoj. La inventaro estas tabelo de prefikso, posedanto kaj celo, kaj ĝi estas la sola artefakto, kiu malhelpas doni la saman areon dufoje.

Aldonu la prefiksojn, kiujn vi atendas dum la venonta jaro, ĉar plano, kiu kovras nur hodiaŭ, fiaskas ĉe la unua nova retejo. Marku en ĉiu vico, kiu povas ŝanĝi ĝin, ne nur kiu posedas ĝin.

Ĝuste la reuzado igas tion malfacila: la privata spaco estas finia kaj ĉiu organizo rigardas 10.0.0.0/8 kiel sian propran. Plano ne povas promesi, ke estonta gastiga LAN ne surteriĝos sur unu el viaj prefiksoj, do la dezajno devas diri, kio okazas, kiam ĝi faras tion. Du reguloj faras la plej grandan parton de la laboro. Metu klientajn basenojn en unu apudan blokon, kiun vi povas resumi, kaj neniam asignu areon, kiun alia teamo jam enkursigas. Ĉio alia estas registro, kiun iu tenas aktuala.

Kial interkovro venkas la enkursigan tabelon

Itinero estas prefikso plus sekva salto, kaj plusendo elektas la plej longan kongruan prefikson. Kiam du kunuloj ambaŭ postulas 192.168.1.0/24, la tabelo tenas unu rikon por ĝi, do trafiko por ambaŭ retejoj eliras tra la sama tunelo. La dua retejo ne estas misagordita; ĝi estas neatingebla ĉar la unua respondas por la samaj adresoj. Neniu metriko povas disigi ilin, ĉar la kongruo okazas antaŭ ol metrikoj estas konsultitaj.

La fiasko estas nesimetria kaj facile mislegata. Gastigantoj ĉe retejo A atingas la enirejon kaj kelkajn servojn, dum la gastigantoj de retejo B respondas nenion, kaj la protokolo montras sanan tunelon en ambaŭ direktoj. Tiu ŝablono estas adresa kolizio, ne fuŝo de aŭtentigo aŭ fajroŝirmilo, kaj konfirmi ĝin postulas unu tabelan eltiraĵon komparatan kun la inventaro.

Intence dimensionu la klientan basenon kaj la retejajn areojn

VPN-klienta baseno estas areo, kiun la enirejo disdonas unu adreson samtempe, do ĝia grandeco limigas samtempecon. /24 entenas 254 uzeblajn adresojn, kio estas malavara por malgranda teamo kaj streĉa por branĉo, kiu rulas ujojn; /22 kostas nenion plie ene de la privata spaco kaj forigas la disputon. Tenu la basenon apuda kaj for de ĉiu reteja LAN, por ke la resuma itinero al klientoj neniam englutu retejon. Rezervu la areon eĉ dum la baseno estas malplena, ĉar la neskribita areo estas tiu, kiun la sekva inĝeniero asignos.

Retejoj ricevas areojn dimensionitajn por atendataj gastigantoj plus kresko, vicigitaj sur limo, kiu resumiĝas pure. Intencaj breĉoj inter asignoj kostas nenion kaj aĉetas spacon por posta agregado.

Poste kontrolu la direkton, kiun homoj forgesas: la revenan vojon. Ĉiu reteja enkursigilo bezonas itineron al la klienta baseno, kaj la koncentrilo bezonas itineron al ĉiu reteja prefikso, kiun ĝi servas. Bela prefiksa tabelo sen vojo reen al la baseno ankoraŭ estas rompita dezajno, kaj la simptomo estas unudirekta konekto, kiu respondas nenion. Tenu ambaŭ direktojn en la sama tabelo kaj revizuu ĝin ĉiam, kiam retejo aldoniĝas.

Tradukado kaj renombrado solvas malsamajn problemojn

Kiam interkovro jam ekzistas, estas du honestaj opcioj kaj unu malhonesta. Renombrado forigas la kolizion por ĉiam kaj kostas prizorgan fenestron plus ĉiun hardkoditan adreson, kiun vi forgesis. Adresa tradukado mapas la privatan areon de unu flanko en alian areon ĉe la tunela rando, kio lasas ambaŭ retejojn netuŝitaj sed aldonas staton, rompas protokolojn, kiuj enkorpigas adresojn, kaj malfaciligas legi protokolojn. La malhonesta opcio estas gastiga itinero al unu servilo, kiu pasas unu teston kaj fiaskas ĉe ĉio alia.

Elektu laŭ kontrolo kaj vivo-daŭro. Retejo, kiun vi posedas kaj povas plani, apartenas al la renombra vojo; partnersa reto, kiun vi ne povas tuŝi, uzata por unu aplikaĵo, estas kandidato por tradukado kun dokumentita mapado. Skribu tiun mapadon, ĉar tradukado, kiu ekzistas nur ene de agorda dosiero, malaperas en la momento, kiam la dosiero anstataŭiĝas.

Testu el la malproksima flanko antaŭ ol disfaldi

Testu el reto, kiu ne gastigas la enirejon, ĉar la propra LAN de la enirejo kaŝas plej multajn enkursigajn erarojn. Konektu klienton malantaŭ ordinara hejma enkursigilo, poste atingi servon en ĉiu retejo kaj unu ene de la klienta baseno. Testu ankaŭ la kontraŭan direkton, de reteja gastiganto al la kliento, ĉar revenaj vojoj fiaskas sendepende. Testo, kiu nur pingu la enirejon, pruvas, ke la tunelo funkcias, kaj nenion pli.

Tenu areojn, posedantojn kaj tradukajn mapadojn en unu komuna registro, kiun la sekva retejo legas antaŭ ol asigni ion ajn. Revizuu ĝin, kiam retejo aldoniĝas, kaj traktu nedokumentitan areon kiel difekton, ne kiel surprizon.

La registro estas la liveraĵo. Plano, kiu vivas en la memoro de tri homoj, fiaskas la unuan fojon, kiam unu el ili estas en ferioj, kaj interkovro trovita en produktado kostas pli, ol la tabelo estus kostinta.