VPN-átállás IOS-ről ASA-ra: a megállapodást fordítsa, ne a parancsokat
A kriptotérkép nem ASA-alagútcsoport. A megállapodás mely részei vihetők át, melyeket kell újraépíteni, és mely ellenőrzések bizonyítják, hogy a szolgáltatás működik.
Az ASA-migráció referenciájaként érkező IOS-konfiguráció egy platform szintaxisába csomagolt megállapodást ír le. A társak címei, az identitások és a védett tartományok alkotják a megállapodást. A kulcskarika, a profil és a kriptotérkép-lánc az, ahogyan az IOS kifejezi, míg az ASA ugyanezt a szándékot alagútcsoportokon és azok attribútumain keresztül fejezi ki. A második rész másolása soha nem működik, és csak az első másolása félkész munkát hagy.
Járja végig az alábbi öt lépést sorrendben, és álljon meg mindenhol, ahol a két platform különböző dolgokat ír le, nem különböző szavakat.
1. lépés: válassza el a megállapodást a szintaxistól
Írja le az átadást olyan követelményekként, amelyekben mindkét adminisztrátor egyetért. Négy sor szinte mindent lefed: hol van a társ és melyik fél kezdeményez, hogyan bizonyítja mindkét fél az identitását, milyen védelem elfogadható, és mely alkalmazásoknak kell túlélniük az alagutat. Egyik sor sem említ parancsot.
Őrizze meg az eredeti szöveget bizonyítékként, ne utasításként. Egy sor, amely az egyik platformon létezik és a másikon nem, szintaktikai különbség, amíg meg nem vizsgálta, teljesíthető-e ugyanaz a követelmény más módon.
| Requirement | What must be agreed |
|---|---|
| Peer delivery | Outer endpoint, address family, NAT view, initiating side |
| Authentication | IKE version, expected identities, credential method and delivery |
| Data protection | Permitted suites, protected ranges, intentional translation |
| Application | Routes, return routes, resources beyond the tunnel |
2. lépés: nevezze meg az objektumokat platformonként
Az IOS XE-ben az IKEv2 kulcskarika táplál egy IKEv2 profilt, és ezt a profilt kriptotérképen vagy IPsec profilon keresztül csatolják. Az ASA-n az alagútcsoport tartja a kapcsolatprofilt és annak IPsec attribútumait, és a kriptotérkép rá mutat, ahogyan azt a kapcsolatprofil útmutatója leírja. Ezek különböző objektumgráfok eltérő öröklődéssel, ezért a soronkénti leképezés olyan konfigurációt ad, amely elemződik, de nem kapcsolódik.
A célobjektumokat a követelménysorokból építse fel, ne a forrássorokból. Ha a sorok teljesek, a célkonfiguráció tervezési döntés. Ha nem, semmilyen mennyiségű parancsfordítás nem adja meg a hiányzó szándékot.
3. lépés: identitást vigyen át, ne csak címeket
Az identitás az a rész, amely csendben eltörik. A cím alapján hitelesítő társ másként viselkedik, mint az, amelyik tanúsítvány tárgya vagy FQDN alapján hitelesít, és a két platform ezt az elvárást különböző helyeken rögzíti. Őrizze meg a szándékolt identitást és bizalmi láncot, ahelyett hogy közös titkot cserélne, mert azt könnyebb tesztelni.
Tartsa az előre megosztott titkot az összehasonlító jegyzeteken és ticketeken kívül. Jegyezze fel, ki birtokolja és hogyan mozog jóváhagyott csatornán, és ne feledje, hogy egy dokumentációs példa helyőrzője nem az ügyfél hitelesítő adata.
4. lépés: egyezzen meg a védelemről az átállás előtt
Ne vigyen át régi kriptográfiai beállításokat csak azért, mert szerepelnek a kapott szövegben. Egyezzen meg azoknak a csomagoknak a metszetében, amelyeket mindkét telepített társ jelenleg támogat, és erősítse meg a másik adminisztrátorral a változási ablak előtt. Ha ez a metszet eltér attól, amit a meglévő társ vár, az összehangolt változás, nem helyi szerkesztés.
Írja le a megállapodott készletet. Két adminisztrátor, akiknek eltérő emlékei vannak egy telefonbeszélgetésről, az az oka, hogy az átállás a második fázisban eltérést okoz.
5. lépés: a szolgáltatást ellenőrizze, ne a szintaxist
Először a cél effektív objektumait ellenőrizze, aztán az elfogadott társítást, aztán egy valódi alkalmazásfolyamot és annak válaszát. A parancs hibamentes bevitele a szintaxist bizonyítja és semmi mást. Az alagút, amely feljön és nem szállít forgalmat, általában azt jelenti, hogy a védett tartományok vagy a visszatérő útvonal nem egyezik a másik oldallal, ami követelménysor-probléma, nem parancsprobléma. Hasonlítsa össze a védett tartományokat mindkét oldalon, mielőtt újra hozzányúl a kriptotérképhez.
Jegyezze fel, mit ellenőrzött, milyen címekkel, melyik oldalról. Ez a feljegyzés a VPN működéséről szóló homályos állítást olyasmivé alakítja, amit a másik adminisztrátor önállóan ellenőrizhet.
Mit kell visszaadni
Küldje el a követelménymátrixot, a célkonfiguráció összefoglalóját és az ellenőrzési eredményeket. Mondja ki egyértelműen, mely forrásbeállításokat nem vitte át, és miért. Ez a lista hasznosabb a lefordított konfigurációnál, mert a következő nézeteltérés ott fog kezdődni.
Tartsa meg a forrásszöveget is a ticket mellett. Az dokumentálja, mit kértek, míg a mátrix azt, miben állapodtak meg.