Cisco ASA tunneled standertrûte: wann't it echt jildt

In brûker fan remote tagong berikt neat foarby de ASA, wylst deselde tsjinner ping fan it ynterne LAN beantwortet. De tunnel komt op, de klient krijt in adres út de pool, en it pakket giet dochs fuort oer de ynternet standertrûte of ferdwynt. Dat patroan betsjut meastentiids dat it decrypteare ferkear gjin eigen rûte fûn en nei de gewoane standertrûte foel. De oplossing is net noch in NAT-regel; it is de tunneled standertrûte.

Begjin mei it symptoom, net mei de konfiguraasje

Sjoch wêr't it pakket hinne giet, ynstee fan wêr't jo ferwachten dat it hinne soe. In opname op 'e bûtneste interface by in mislearre sesje lit it decrypteare pakket sjen dat nei de ISP-gateway giet mei it pooladres noch yntakt, of lit neat sjen om't it sykjen mislearre. Yn beide gefallen is de tunnel net it probleem.

De tunnel liket sûn yn show vpn-sessiondb, en dat is krekt wêrom't minsken trochgeane mei it debuggen fan IKE.

Wat dit fan in ACL-drop skiedt, is de rjochting. In ACL-drop wurdt logd en teld, wylst in ûntbrekkende rûte in mislearre sykjen sûnder byhearrende yngong jout. Rin show route foar it bestimmingsplak fan 'e klient en lês wat de ASA eins keas, ynklusyf oft in standertrûte keazen waard en hokker.

Hoe't it tunneled-sykjen ferskilt

Cisco syn hânlieding foar statyske routing yn ASA 9.23 dokumintearret in aparte standertrûte foar decrypteare VPN-ferkear dat gjin statyske of learde rûte hat. It kaaiwurd tunneled markearret dy rûte, sadat in decrypteare pakket weromfalle kin nei in oare folgjende hop as dy't de ASA foar syn eigen transport brûkt. Mear spesifike rûtes winne noch altyd, en dêrom kin in klient 10.0.0.0/8 berikke fia de ynterne gateway en al it oare ferlieze.

In minimaal útsjoch hâldt twa standertrûtes mei ferskillende folgjende hops. Ien draacht it eigen ferkear fan 'e ASA, en ien draacht decrypteare ferkear sûnder bettere rûte. Beide folgjende hops moatte noch berikber wêze fan 'e interface dêr't jo se oan fêstmeitsje.

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

As beide standertrûtes nei deselde folgjende hop wize, feroaret it kaaiwurd neat en sil it symptoom net bewege.

De beheiningen dy't beslute oft it wurket

Deselde hânlieding lit mar ien tunneled standertrûte ta en stelt dat ECMP derfoar net stipe wurdt, dat jo kinne dy rûte net lêstferdiele. It listet ek beheiningen op oangeande it folgjen fan rûtes, ferifikaasje fan 'e weromwei en guon ynspeksje- en behearstreamen. Lês dy tsjin jo ynstallearre ferzje foardat jo om 'e funksje hinne ûntwerpe. In ûntwerp dat se negearret, mislearret meastentiids op ien bepaald plak ynstee fan oeral, en dêrom liket it symptoom tuskentyldich.

Ferifikaasje fan 'e weromwei is dejinge dy't byt yn asymmetryske ûntwerpen. As it antwurd fia in oare interface soe oankomme as de ASA ferwachtet, wurdt it pakket fuortsmiten foardat routing wat ûtmakket. Reparearje de topology of de weromwei ynstee fan 'e ferifikaasje ût te skeakeljen om in folgjende hop te twingen.

Rûtes folgje is in aparte falstrik: it folge objekt beskermet meastentiids de gewoane standertrûte, net de tunneled-ien.

Wat it kaaiwurd net docht

It kiest net it boarneadres dat de ASA brûkt om IKE te bouwen. It bûtneste einpunt fan 'e tunnel folget de eigen interface- en boarneseleksje fan it platfoarm, en de tunneled standertrûte hat gjin oandiel yn dat beslút. It feroarjen sil in phase 1 net reparearje dy't fan it ferkearde adres komt.

It makket de folgjende hop ek net ta in proxy. As it bestimmingsplak in HTTP CONNECT-ûtwikseling ferwachtet, jout it stjoeren fan rauwe IP-pakketten nei in proxy-host jo allinnich in host dy't se net routearret. Konfigurearje ynstee it proxy-meganisme dat de klient stipet.

En it skept gjin troerstjoerren streamôf. De gateway dêr't jo nei wize hat noch altyd in rûte werom nei de VPN-pool nedich, plus boarnetranslaasje wêr't it ûntwerp dat easket.

Ferifiearje it paad fan begjin oant ein

Nei't de rûte op syn plak is, kontrolearje fjouwer dingen yn folchoarder: show route foar in bestimmingsplak dat de pool nedich hat, in opname op 'e interface nei de nije folgjende hop, in opname op 'e gateway sels, en in weromwei fan dy gateway nei it pooladres. De earste twa bewize dat de ASA it paad keas, en de lêste twa bewiize dat immen derop antwurdet.

As de gateway antwurdet mar de klient sjocht nea in antwurd, sjoch dan nei de boarnetranslaasje en de antwurd-rûte foardat jo de routingtabel wer oanreitsje.

Skriuw de ferzje op dêr't jo op falidearre hawwe, want de beheiningslist is ferzjespesifyk en in ûntwerp dat op ien trein wurket, kin op in oare in oar paad nedich wêze. Dat notysje libbet langer as it konfiguraasjestikje.