Migrarea VPN de la IOS la ASA: traduci acordul, nu CLI-ul
Un crypto map nu este un tunnel-group ASA. Ce părți ale acordului se transferă, ce trebuie reconstruit și verificările care dovedesc că serviciul funcționează.
O configurație IOS care sosește ca referință pentru o migrare la ASA descrie un acord învelit în sintaxa unei platforme. Adresele perechilor, identitățile și intervalele protejate sunt acordul. Lanțul de key ring, profil și crypto map este felul în care IOS îl exprimă, în timp ce ASA exprimă aceeași intenție prin tunnel groups și atributele lor. Copierea celei de-a doua părți nu funcționează niciodată, iar copierea doar a primei lasă treaba pe jumătate făcută.
Parcurgeți cei cinci pași de mai jos în ordine și opriți-vă acolo unde cele două platforme descriu lucruri diferite, nu cuvinte diferite.
Pasul 1: separă acordul de sintaxă
Scrieți predarea ca cerințe asupra cărora ambii administratori sunt de acord. Patru rânduri acoperă aproape tot: unde este perechea și care parte inițiază, cum își dovedește fiecare parte identitatea, ce protecție este acceptabilă și ce aplicații trebuie să supraviețuiască tunelului. Niciunul dintre aceste rânduri nu menționează o comandă.
Păstrați textul original ca dovadă, nu ca instrucțiuni. O linie care există pe o platformă și nu pe cealaltă este o diferență de sintaxă până când verificați dacă aceeași cerință poate fi îndeplinită altfel.
| 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 |
Pasul 2: numește obiectele pe fiecare platformă
Pe IOS XE un key ring IKEv2 alimentează un profil IKEv2, iar acel profil este atașat printr-un crypto map sau un profil IPsec. Pe ASA un tunnel group ține profilul de conexiune și atributele lui IPsec, iar crypto map-ul indică spre el, așa cum descrie ghidul profilului de conexiune . Sunt grafuri de obiecte diferite cu moșteniri diferite, motiv pentru care o mapare linie cu linie produce o configurație care se parsează și nu se conectează.
Construiți obiectele țintă din rândurile de cerințe, nu din liniile sursă. Dacă rândurile sunt complete, configurația țintă este o decizie de proiectare. Dacă nu sunt, nicio traducere de comenzi nu va furniza intenția lipsă.
Pasul 3: du identitatea, nu doar adresele
Identitatea este partea care se rupe în tăcere. O pereche care se autentifică prin adresă se comportă altfel decât una care se autentifică prin subiectul certificatului sau FQDN, iar cele două platforme înregistrează această așteptare în locuri diferite. Păstrați identitatea și lanțul de încredere dorite în loc să înlocuiți cu un secret partajat pentru că e mai ușor de testat.
Țineți secretul prepartajat în afara notițelor de comparație și a tichetelor. Înregistrați cine îl deține și cum circulă printr-un canal aprobat, și amintiți-vă că un substituent dintr-un exemplu de documentație nu este credențialul clientului.
Pasul 4: conveniți protecția înainte de comutare
Nu duceți mai departe setări criptografice vechi doar pentru că apar în textul furnizat. Conveniți o intersecție de suite pe care ambele perechi implementate o acceptă acum și confirmați-o cu celălalt administrator înainte de fereastra de schimbare. Dacă acea intersecție diferă de ce așteaptă perechea existentă, este o schimbare coordonată, nu o editare locală.
Scrieți setul convenit. Doi administratori cu amintiri diferite despre un apel telefonic este felul în care o comutare produce o nepotrivire în faza a doua.
Pasul 5: verifică serviciul, nu sintaxa
Verificați mai întâi obiectele efective ale țintei, apoi asocierea acceptată, apoi un flux real de aplicație și răspunsul lui. Introducerea unei comenzi fără eroare dovedește sintaxa și nimic altceva. Un tunel care se ridică și nu transportă trafic înseamnă de obicei că intervalele protejate sau ruta de întoarcere nu sunt de acord cu cealaltă parte, ceea ce este o problemă de rând de cerințe, nu de comandă. Comparați intervalele protejate de ambele părți înainte de a atinge din nou crypto map-ul.
Notați ce ați verificat, cu ce adrese, din ce parte. Acea notă transformă o afirmație ambiguă că VPN-ul este activ în ceva ce celălalt administrator poate verifica independent.
Ce trebuie predat înapoi
Trimiteți matricea cerințelor, un rezumat al configurației țintă și rezultatele verificării. Declarați explicit ce setări sursă nu ați preluat și de ce. Acea listă este mai utilă decât configurația tradusă, pentru că acolo va începe următoarea neînțelegere.
Păstrați și textul sursă împreună cu tichetul. El documentează ce s-a cerut, în timp ce matricea documentează ce s-a convenit.