Egy távoli hozzáférésű felhasználó semmit nem ér el az ASA mögött, miközben ugyanaz a szerver válaszol a belső LAN felől érkező pingekre. Az alagút feljön, az ügyfél címet kap a poolból, a csomag mégis az internetes alapértelmezett útvonalon távozik, vagy eltűnik. Ez a minta általában azt jelenti, hogy a visszafejtett forgalom nem talált saját útvonalat, és a közönséges alapértelmezett útvonalra esett vissza. A megoldás nem egy újabb NAT-szabály; a megoldás a tunneled alapértelmezett útvonal.

Kezdje a tünettel, ne a konfigurációval

Azt figyelje, hová megy a csomag, ne azt, hová várta, hogy menjen. A külső interfészen egy sikertelen munkamenet alatt készített rögzítés megmutatja, ahogy a visszafejtett csomag az ISP átjárója felé tart, a pool címe pedig még érintetlen, vagy semmit nem mutat, mert a keresés meghiúsult. Mindkét esetben nem az alagút a probléma.

Az alagút egészségesnek látszik a show vpn-sessiondb kimenetében, és éppen ezért debugolják az emberek továbbra is az IKE-et.

Az ACL-dobástól az irány különbözteti meg. Az ACL-dobás naplózva és számlálva van, míg a hiányzó útvonal keresési hibát okoz, amelyhez nem tartozik egyező bejegyzés. Futtassa a show route parancsot az ügyfél céljára, és olvassa el, mit választott valójában az ASA, azt is beleértve, hogy alapértelmezett útvonalat választott-e, és melyiket.

Miben tér el a tunneled keresés

A Cisco ASA 9.23 statikus útválasztási útmutatója külön alapértelmezett útvonalat ír le a visszafejtett VPN-forgalom számára, amelynek nincs statikus vagy tanult útvonala. A tunneled kulcsszó jelöli meg azt az útvonalat, így a visszafejtett csomag más következő ugrásra eshet vissza, mint amelyet az ASA a saját átviteléhez használ. A konkrétabb útvonalak továbbra is nyernek, ezért érhet el egy ügyfél a belső átjárón keresztül a 10.0.0.0/8 hálózatig, és veszíthet el minden mást.

Egy minimális elrendezés két alapértelmezett útvonalat tart különböző következő ugrásokkal. Az egyik az ASA saját forgalmát viszi, a másik a visszafejtett forgalmat, amelynek nincs jobb útvonala. Mindkét következő ugrásnak elérhetőnek kell lennie arról az interfészről, amelyhez csatolja őket.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Ha mindkét alapértelmezett útvonal ugyanarra a következő ugrásra mutat, a kulcsszó semmit nem változtat, és a tünet nem mozdul.

A megkötések, amelyek eldöntik, működik-e

Ugyanez az útmutató csak egy tunneled alapértelmezett útvonalat engedélyez, és kimondja, hogy az ECMP nem támogatott hozzá, így nem oszthatja meg a terhelést azon az úton. Korlátozásokat is felsorol az útvonalkövetésre, a fordított útvonal ellenőrzésére, valamint bizonyos vizsgálati és kezelési folyamatokra vonatkozóan. Ezeket a telepített kiadásához mérten olvassa el, mielőtt a szolgáltatás köré tervez. A megkötéseket figyelmen kívül hagyó tervezés általában nem mindenhol, hanem egy adott ponton hibázik, ezért tűnik a tünet időszakosnak.

A fordított útvonal ellenőrzése az, amely az aszimmetrikus tervekbe beleharap. Ha a válasz más interfészen érkezne, mint amelyet az ASA vár, a csomag még azelőtt eldobódik, hogy az útválasztás számítana. A topológiát vagy a visszautat javítsa, ne az ellenőrzés kikapcsolásával kényszerítsen ki egy következő ugrást.

Az útvonalkövetés külön csapda: a követett objektum rendszerint a közönséges alapértelmezett útvonalat őrzi, nem a tunneledet.

Amit a kulcsszó nem tesz

Nem választja ki azt a forrás címet, amelyet az ASA az IKE felépítéséhez használ. A külső alagútvégpont a platform saját interfész- és forrásválasztását követi, és a tunneled alapértelmezett útvonalnak nincs része ebben a döntésben. Ennek megváltoztatása nem javít meg egy olyan phase 1-et, amely rossz címről indul ki.

A következő ugrást sem változtatja proxyvá. Ha a cél HTTP CONNECT cserét vár, a nyers IP-csomagok proxy hosztra küldése csak egy olyan hosztot ad, amely nem továbbítja azokat. Inkább az ügyfél által támogatott proxy mechanizmust állítsa be.

És nem hoz létre további továbbítást. Az átjárónak, amelyre mutat, továbbra is kell egy útvonal vissza a VPN pool felé, valamint forrásfordítás ott, ahol a terv megköveteli.

Ellenőrizze az útvonalat végponttól végpontig

Miután az útvonal a helyén van, sorrendben négy dolgot ellenőrizzen: show route egy olyan célra, amelyet a poolnak el kell érnie, rögzítés az új következő ugrás felé vezető interfészen, rögzítés magán az átjárón, és visszaút attól az átjárótól a pool címéhez. Az első kettő bizonyítja, hogy az ASA az adott utat választotta, az utolsó kettő pedig azt, hogy valaki válaszol rajta.

Ha az átjáró válaszol, de az ügyfél soha nem lát választ, nézze meg a forrásfordítást és a visszautat, mielőtt újra hozzányúlna az útválasztási táblához.

Jegyezze fel a kiadást, amelyen ellenőrizte, mert a korlátozások listája verziófüggő, és egy vonaton működő tervnek máson más útra lehet szüksége. Ez a feljegyzés tovább él, mint a konfigurációs részlet.

Kapcsolódó cikkek