ASA-hairpin: internetuittree of site-tot-site-VPN-been?

Die kliëntpoel kan na die internet of in ’n site-VPN vertrek. Besluit watter been jy nodig het voordat jy NAT skryf, en kyk dan na roete, selektor en antwoordpad.

Twee remote-access-gebruikers agter dieselfde ASA kan verkeer uit dieselfde buitenste koppelvlak stuur en heeltemal anders behandel word. Die een gaan na ’n openbare webwerf, so die pakket het brontranslasie en ’n internetroete nodig. Die ander gaan na ’n bediener agter ’n site-tot-site-tonnel wat ook op daardie koppelvlak eindig, so die pakket het identiteit, ’n passende tonnelselektor en ’n terugpad na die kliëntpoel nodig. Toestemming vir dieselfde koppelvlak is ’n voorwaarde vir albei en ’n oplossing vir nie een nie.

Twee bene, een koppelvlak

Besluit watter been jy bou voordat jy ’n NAT-reël tik, want die reëls is nie uitruilbaar nie. Been A is kliënt na internet: poeladres in, vertaalde openbare adres uit, terug deur dieselfde koppelvlak. Been B is kliënt na ’n private voorvoegsel aan die oorkant van ’n ander IPsec-eweknie: poeladres bly behoue, word herversleutel en by ’n eweknie afgelewer wat moet weet hoe om die poel te antwoord.

Wat albei eerste nodig het, is die toestemming vir dieselfde koppelvlak. Sonder dit weier die ASA om ’n pakket uit die koppelvlak te stuur waarop dit aangekom het, en die fout lyk soos ’n roeteprobleem eerder as ’n beleidsprobleem:

same-security-traffic permit intra-interface

Daardie een reël magtig ’n aanstuur-reëling, soos die ASA-NAT-verwysing dit vir dieselfde-koppelvlak-paaie beskryf. Dit voeg geen kliëntroete by nie, magtig geen hulpbron nie, vertaal geen adres nie en onderhandel geen IPsec-selektor nie, so verwag om daarna nog drie of vier dinge by te voeg en moenie die aanvaarding daarvan as vordering lees nie.

Been A: die kliënt wil die internet

Vir ’n internetuittree moet die poeladres ophou privaat wees voordat die pakket die toestel verlaat. Op ’n gewone PAT-ontwerp vertaal die reël die poel na die adres van die buitenste koppelvlak, en die terugkeertoestand herstel die kliëntgerigte vloei:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Bevestig dan dat die kliënt die ASA werklik gevra het om daardie verkeer te dra. ’n Split-tonnel-uitsluiting stuur die openbare bestemming oor die telefoon se eie verbinding, wat die ASA glad nie bereik nie, en geen NAT-reël herstel ’n pakket wat nooit gestuur is nie. Vergelyk die groepbeleid se split-tonnel-lys met die bestemming wat jy toets.

Die res van die been is gewoon: ’n bruikbare verstek- of spesifieke roete uit die buitenste koppelvlak, ’n toegangsbeleid wat die vloei toelaat, en DNS wat volgens die resolverbeleid wat jy gekies het, hanteer word. Voeg route-lookup hier by om dieselfde rede as hieronder, aangesien die in- en uitgangskoppelvlak identies is.

Been B: die kliënt wil ’n private site

Hierdie been faal op meer plekke, so skryf dit in volgorde. Eerste die kliëntroete: die bestemmingsvoorvoegsel moet in die split-tonnel-lys wees, anders plaas die kliënt dit nie in die tonnel nie. Tweede die tonnelselektor: die site-tot-site-kripto-ACL moet poeladres na afgeleë voorvoegsel dek, nie net die plaaslike LAN na die afgeleë voorvoegsel nie. Derde identiteit, sodat die poeladres nie onderweg in die internet-PAT vertaal word nie.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Die oorkant is die deel wat mense vergeet om te toets. Die eweknie het ’n roete terug na die poel nodig en ’n selektor wat dit insluit, en sy eie beleid moet die bronadresse toelaat wat hy sal sien. Word die site eerder deur ’n vertaalde aansig gebruik, is dit ’n geldige ontwerp, maar dan moet albei eweknieë, albei selekterende inskrywings en albei roetetabelle oor dieselfde vertaalde adresse saamstem.

Kyk ook na die reëlvolgorde. ’n Breë PAT-reël bo die identiteitsreël sal die private uitruiling vertaal voordat die identiteitsreël ooit geëvalueer word, en die simptoom is ’n sitetonnel sonder ’n passende SA eerder as ’n NAT-fout.

Die toets wat jou sê watter been jy gebou het

Gebruik die ASA se eie pad-evaluering in plaas daarvan om die konfigurasie te lees en te hoop. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed wys die NAT-besluit, die roete en die ACL-uitkoms vir een vloei; herhaal dit met ’n private bestemming. As die NAT-fase ’n privaat-na-privaat-vloei herskryf, het jy been A gebou vir ’n pakket wat been B nodig gehad het.

Nog twee opdragte sluit die gaping. show nat detail druk die reëlvolgorde wat packet-tracer gevolg het, en show crypto ipsec sa wys of ’n selektor bestaan vir die paar wat jy verwag. ’n Ontbrekende SA is ’n selektor- of eweknie-konfigurasieprobleem, nie iets wat die NAT-reël kan herstel nie.

Verifieer elke been met die verkeer wat dit bedien

Aanvaar been A met ’n gewone openbare versoek van die kliënt, en aanvaar been B met ’n versoek na ’n private hulpbron wat werklik bestaan. Herhaal dan elkeen met ’n geweierde hulpbron, want “toegelaat” en “deur die toegangsbeleid toegestaan” is nie dieselfde bewys nie, en ’n ping wat by die hub ontstaan oefen nie een van die kliëntpaaie nie.

Hou die twee toetsrekords apart in die kaartjie: bronadres, bestemming, NAT-reël wat gepas het, en resultaat. Wanneer die volgende verslag sê “die VPN is stukkend”, sê daardie paar jou binne ’n minuut watter been agteruitgegaan het, en die antwoord is gewoonlik ’n roete of ’n selektor eerder as die same-koppelvlak-reël wat almal eerste verdink.

Verwante artikels