Migrado for de PPP-bazita VPN sen kopii ĝiajn supozojn

VPN-migrado estas finita kiam la uzantoj, celoj, nomrezolucio kaj fiaskokonduto ankoraŭ ĉiuj estas ĝustaj, ne kiam la nova kliento montras verdan ikonon. Malnovaj PPP-bazitaj enkondukoj portas supozojn, kiuj neniam estis skribitaj: komuna sekreto, kiu duoblis kiel la sola identecokontrolo, fiksa adresa provizo, kiun la fajroŝirmilo havas en la permeslisto, DNS-sufikso, kiun la servilo puŝas. Anstataŭigi la protokolon sen inventari tiujn supozojn produktas tunelon, kiu plenumas la manpremon, kaj limon, kiu ne ekzistas. La sekva sinsekvo estas la ordo, kiun mi uzas, kaj la lasta paŝo estas tiu, kiun teamoj saltas.

Paŝo 1: inventaru, kion la malnova konekto provizas

La inventaro estas skribata, ne memorata. Notu la subtenatajn klientojn, la aŭtentikigajn rolojn, la adresajn provizojn, la protektitajn retojn, la DNS-postulojn kaj la servopermesojn, kiujn ĉiu uzantgrupo bezonas.

Por L2TP/IPsec, apartigu la du tavolojn eksplicite. La identeco de la IPsec-partnero aŭtentikigas la maŝinojn; PPP aŭtentikigas la uzanton, kutime per CHAP aŭ MSCHAPv2.

Ĝuste en tiu apartigo malnovaj enkondukoj kaŝas siajn supozojn. Antaŭe kunhavigita ŝlosilo, kiun ĉiu kliento dividas, aŭtentikigas grupon anstataŭ aparaton, kaj ĝi ofte estas la sola afero, kiu iam estis rotaciita. Se la PPP-konto estas la reala kontrolo por uzanto, diru tion, ĉar la anstataŭigo devas reprodukti tiun kontrolon per io, kio ne estas komuna signoĉeno. Notu ankaŭ fiksajn fontadresojn kaj lokretajn esceptojn, ĉar tiuj estas la dependecoj, kiujn neniu dokumentas ĝis ili rompiĝas.

Paŝo 2: projektadu la anstataŭigon intence

Elekti la anstataŭigon estas mapado postulo post postulo: protokolo kaj prizorgata kliento, kiujn la organizo subtenas, kun ĉiu identeca kaj alira postulo finiĝanta en reala meĥanismo. Komuna sekreto ne aŭtomate egalas al ŝlosilo aŭ atestilo por aparato, kaj PPP-konto por uzanto ne egalas al aparata atestilo.

Kunordigu la adresajn gamojn antaŭ ĉio alia, ĉar anstataŭa provizo, kiu interkovras hejman aŭ oficejan LAN-on, kreas fiaskon, kiu havas nenion komunan kun ĉifropotenco. Kontrolu la provizon kontraŭ la sama listo, kiun vi konstruis por la malnova servo, plus tion, kion la nova kliento supozas defaŭlte. Konfirmu la returnan itinadon por la protektitaj retoj kaj konfirmu, ke la nova kliento povas puŝi aŭ dokumenti la DNS-sufikson, kiun la malnova puŝis. Tiuj du eroj kaŭzas pli da migraj biletoj ol la protokolŝanĝo mem.

Paŝo 3: enkonduku laŭetape kaj kontrolu kaj permeson kaj malpermeson

Enkonduku kun unu reprezenta uzanto kaj unu reprezenta aplikaĵo. Inkluzivu privatan DNS-rezolucion en la testo, ĉar tunelo, kiu atingas adreson sed ne povas solvi internan nomon, estas nur duone migrita. Inkluzivu ankaŭ la atendatan nehaveblan staton: kio devus okazi kiam la tunelo falas, kaj ĉu la kliento devigas ĝin.

Poste testu celon, kiu devus resti malpermesita. Larĝa portempa permesregulo povas igi la novan tunelon aspekti sana dum ĝi silente forigas la rajtigan limon, kiun la malnova servo devigis, kaj neniu rimarkas ĝin ĝis revizio. Komparu la rezultojn de permeso kaj malpermeso flanko ĉe flanko, el la sama kliento, en la sama sesio. Tenu la malnovan servon funkcianta ĝis ambaŭ kolumnoj kongruos kun la projektado.

Antaŭ ol vi translokos administran aliron, konfirmu, ke vi havas rajtigitan reakiran vojon, kiu ne dependas de la tunelo, kiun vi ŝanĝas.

Paŝo 4: retiru la malnovan identecon

Taŭge retiri la malnovan identecon signifas revoki eksdatajn uzantojn kaj aparatajn akreditaĵojn per la servo, kiu posedas ilin, poste forigi malnovajn profilojn kaj aŭskultantojn kiam neniu dependeco restas. Forigi lokan dosieron ne revokas kopion aliloke, kaj malnova aŭskultanto, kiu ankoraŭ akceptas la malnovan komunan sekreton, estas pordo sen gvatado.

Tiu punkto indas malrapidigi. Malŝaltita klienta profilo en tekkomputilo ne estas revokita akreditaĵo; la akreditaĵo vivas sur la servilo kaj restas valida ĝis la servilo ĉesas akcepti ĝin. Serĉu aliajn kopiojn de la malnova agordo — testaparatoj, forgesita telefono, instalilo, kiun iu konservis — kaj traktu la malŝalton de la aŭskultanto kiel la momenton, kiam la malnova servo vere finiĝas. Ĝis tiam, la migrado havas du antaŭajn pordojn.

La akceptprotokolo estas la inventaro el la unua paŝo kun aldonita kolumno: kion la nova projektado faras por ĉiu vico, kaj kiel vi kontrolis ĝin. Tio transformas protokolajn ĝisdatigon en servopostulon kun pruvoj.

Tenu la rezulton ligita al tio, kion la servo bezonas, anstataŭ al la protokola nomo, ĉar moderna protokolo kun la malnovaj supozoj kopiitaj en ĝin estas la sama risko kun pli bona kadro. RFC 3193 priskribas, kiel L2TP estas portata super IPsec, kio estas utila memorigo, ke la du tavoloj ĉiam estis apartaj decidoj. Se la inventaro havas vicon, kiun vi ne povas klarigi, haltu kaj trovvu, kio dependas de ĝi. La migrado finiĝas kiam la listo enuas.