Cisco ASA se tonnel-verstekroete: wanneer dit werklik geld

’n Gebruiker met afstandstoegang kan niks anderkant die ASA bereik nie, terwyl dieselfde bediener wel op pings van die binne-LAN antwoord. Die tonnel kom op, die kliënt kry ’n adres uit die poel, en die pakkie verlaat steeds via die internet-verstek of verdwyn. Daardie patroon beteken gewoonlik dat die ontsleutelde verkeer geen eie roete gevind het nie en na die gewone verstek deurgeval het. Die oplossing is nie nog ’n NAT-reël nie; dit is die tonnel-verstek.

Begin by die simptoom, nie by die konfigurasie nie

Kyk waar die pakkie heen gaan, eerder as waar jy verwag het dit moet gaan. ’n Vangs op die buite-koppelvlak tydens ’n mislukte sessie wys die ontsleutelde pakkie op pad na die ISP-ghid met die poel-adres nog ongeskonde, of wys niks omdat die opsoek misluk het. In beide gevalle is die tonnel nie die probleem nie.

Die tonnel lyk gesond in show vpn-sessiondb, en dit is presies waarom mense aanhou om IKE te ontfout.

Wat dit van ’n ACL-drop onderskei, is rigting. ’n ACL-drop word gelog en getel, terwyl ’n ontbrekende roete ’n opsoekmislukking sonder ’n passende inskrywing lewer. Voer show route uit vir die kliënt se bestemming en lees wat die ASA werklik gekies het, insluitend of ’n verstek gekies is en watter een.

Hoe die tonnel-opsoek verskil

Cisco se ASA 9.23-gids vir statiese roetes beskryf ’n aparte verstek vir ontsleutelde VPN-verkeer wat geen statiese of geleerde roete het nie. Die sleutelwoord tunneled merk daardie roete, sodat ’n ontsleutelde pakkie na ’n ander volgende hop kan terugval as dié wat die ASA vir sy eie vervoer gebruik. Meer spesifieke roetes wen steeds, en daarom kan ’n kliënt 10.0.0.0/8 deur die interne ghid bereik en alles anders verloor.

’n Minimale uitleg hou twee verstekke met verskillende volgende hops. Een dra die ASA se eie verkeer, en een dra ontsleutelde verkeer wat geen beter roete het nie. Beide volgende hops moet steeds bereikbaar wees vanaf die koppelvlak waaraan jy hulle koppel.

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 verstekke na dieselfde volgende hop wys, verander die sleutelwoord niks en sal die simptoom nie beweeg nie.

Die beperkings wat bepaal of dit werk

Dieselfde gids laat net een tonnel-verstek toe en sê dat ECMP daarvoor nie ondersteun word nie, so jy kan nie daardie pad las-verdeel nie. Dit lys ook beperkings rakende roete-volging, omgekeerde-pad-verifikasie en sekere inspeksie- en bestuursvloeie. Lees dit teen jou geïnstalleerde weergawe voordat jy rondom die funksie ontwerp. ’n Ontwerp wat dit ignoreer, misluk gewoonlik op een spesifieke plek eerder as oral, en daarom lyk die simptoom af en toe opduikend.

Omgekeerde-pad-verifikasie is die een wat byt in asimmetriese ontwerpe. As die antwoord deur ’n ander koppelvlak sou aankom as wat die ASA verwag, word die pakkie laat val voordat roetering saak maak. Maak die topologie of die terugpad reg in plaas daarvan om verifikasie af te skakel om ’n volgende hop af te dwing.

Roete-volging is ’n aparte valstrik: die gevolgde objek beskerm gewoonlik die gewone verstek, nie die tonnel-verstek nie.

Wat die sleutelwoord nie doen nie

Dit kies nie die bronadres wat die ASA gebruik om IKE te bou nie. Die buitenste tonnel-eindpunt volg die platform se eie koppelvlak- en bronkeuse, en die tonnel-verstek het geen deel aan daardie besluit nie. Om dit te verander sal nie ’n phase 1 herstel wat van die verkeerde adres af kom nie.

Dit maak ook nie die volgende hop ’n proxy nie. As die bestemming ’n HTTP CONNECT-uitruiling verwag, gee die stuur van rou IP-pakkies na ’n proxy-gasheer net ’n gasheer wat hulle nie routeer nie. Konfigureer eerder die kliënt se ondersteunde proxy-meganisme.

En dit skep nie stroomaf-waartse aanstuur nie. Die ghid waarheen jy wys, het steeds ’n roete terug na die VPN-poel nodig, plus bron-vertaling waar die ontwerp dit vereis.

Verifieer die pad van begin tot einde

Nadat die roete in plek is, kontroleer vier dinge in volgorde: show route vir ’n bestemming wat die poel nodig het, ’n vangs op die koppelvlak na die nuwe volgende hop, ’n vangs op die ghid self, en ’n terugpad van daardie ghid na die poel-adres. Die eerste twee bewys dat die ASA die pad gekies het, en die laaste twee bewys dat iemand daarop antwoord.

As die ghid antwoord maar die kliënt nooit ’n antwoord sien nie, kyk na bron-vertaling en die antwoordroete voordat jy weer aan die roetetabel raak.

Teken die weergawe aan waarop jy gevalideer het, want die beperkingslys is weergawe-spesifiek en ’n ontwerp wat op een trein werk, kan op ’n ander ’n ander pad nodig hê. Daardie nota leef langer as die konfigurasie-snippet.