Planu subretojn antaŭ loka VPN: renumera aŭ traduku

Du oficejoj ambaŭ uzas 192.168.1.0/24 ĉar neniu planis alie, kaj oni atendas, ke la tunelo solvos tion. Ĝi ne povas: enkursigilo ne povas igi la saman privatan adreson signifi du malsamajn lokojn. La laboro, kiu malhelpas tion, okazas antaŭ ol la unua tunela parametro estas tajpita.

Inventaru ĉiun gamon, inkluzive tiujn, kiujn vi forgesis

Kolektu la LAN-ojn, servilajn segmentojn, klientajn grupojn de fora aliro, nubajn VPC-gamojn kaj ajnajn ujo- aŭ tavol-retojn, kiujn gastigantoj devas atingi. Klientaj grupoj estas tiuj, kiujn homoj forgesas, kaj ili surprize ofte interkovras oficejan gamon ĉar ambaŭ estis elektitaj el la sama defaŭlto. Inkluzivu la administran reton kaj ajnan eksterbandan segmenton.

Notu posedanton, enkursigilon, celon kaj ĉu la prefikso devas esti atingebla de la alia loko. Prefikso, kiu neniam devas trapasi la tunelon, ne devas esti unika, kaj scii tion malpliigas la renumeran laboron.

Faru IPv6 aparte, ĉar ĝia plano kaj ĝiaj interkovroj estas sendependaj.

Komparu prefiksojn, ne konatajn adresojn

Du retoj kun malsamaj gastigantaj adresoj ankoraŭ povas interkovriĝi, ĉar interkovriĝo estas eco de maskoj, ne de la nombroj, kiujn homoj memoras. 10.20.0.0/16 enhavas 10.20.30.0/24 sendepende ĉu iu diras tion laŭte. Komparu plenajn prefiksajn parojn, kaj kontrolu agregatojn kontraŭ la pli malgrandaj retoj ene de ili. Tial la kontrolo apartenas al kalkultabelo, ne al ies kapo.

La sama kontrolo validas por la propra klienta grupo de la VPN kaj por ajna tradukita gamo, kiun vi planas enkonduki, ĉar tradukita gamo, kiu kolizias, estas pli malbona ol la origina interkovriĝo.

Tabelo de prefiksoj kun maskoj sufiĉas; diagramo sen maskoj ne.

Decidu, kio efektive devas transiri

Loko povas enhavi tridek subretojn dum unu serva reto bezonas foran aliron. Komencu de tiu postulo kaj anoncu nur tion, kion ĝi bezonas, ĉar pli malgrandaj anoncoj kaj kongruaj alirreguloj estas pli facile revizieblaj kaj pli malfacile akcidente plivastigeblaj. Anonci ĉiun privatan gamon en uzo estas kutimo, kiu transformas tunelon en ponton. Ju pli mallarĝa la anonco, des pli malgranda la efika radiuso de estonta eraro.

Privata DNS devas redoni adresojn, kiujn la celitaj klientoj povas atingi, do nomo montranta al neanoncita aŭ interkovranta gamo restas rompita eĉ kiam la serĉo sukcesas.

Skribu la alirliston antaŭ la tunela agordo, ne post kiam ĝi malsukcesas.

Renumera aŭ traduku, kaj konu la koston

Renumerado de unu reto estas kutime la plej klara longtempa solvo, kaj ĝi tuŝas rezervojn, aparatojn, DNS, fajroŝirmilajn regulojn kaj ĉion, kio havas adreson bakitan en agordo. Traduki alirgamojn estas la alternativo, kiam renumerado estas nepraktika, kaj ĝi kostas la fontan identecon plus klason de protokoloj, kiuj enkorpigas adresojn en utilŝarĝoj. Elektu unu kaj finu ĝin, ĉar duone renumerita reto estas pli malbona ol ambaŭ elektoj.

Kiun ajn vi elektas, dokumentu kaj la originalan kaj la prezentitan adreson, ĉar ĉiu posta problempuriga konversacio bezonas ilin.

Solvo sen revena vojo ne estas solvo.

Uzu marŝtabelon kiel la akceptan teston

Finu per matrico: loka prefikso, fora prefikso, permesita servo kaj revena enkursigilo. Tiu tabelo estas la akcepta testo, kiam la tunelo ekfunkcias, kaj ĝi ankaŭ estas la dokumento, kiun la sekva inĝeniero legos. Testu de realaj gastigantoj en la elektitaj subretoj, ne de la enkursigiloj.

Ping inter tunelaj adresoj pruvas, ke la tunelo ekzistas, kaj nenion pri la adresplano malantaŭ ĝi.

Konservu la matricon kun la tunela agordo, kaj la sekva loka aldono komenciĝos de datumoj anstataŭ de memoro. La gvidilo de strongSwan pri plusendado kovras la enkursigilan flankon post kiam la plano ekzistas.