Publisere en intern tjeneste over en ASA site-to-site-VPN

Å publisere en tjeneste som lever bak en site-to-site-VPN er én oppgave med fem feilpunkter, og de feiler i fast rekkefølge. Tunnelen kommer opp, oversettelsen stemmer, filialen svarer, og svaret kommer tilbake samme vei. Når noe av dette er feil, viser nettleseren det samme: en tilkobling som henger eller tilbakestilles. Arbeid deg gjennom listen ovenfra og ned og stopp ved den første kontrollen som feiler.

Kontroll 1: tunnelen beskytter kildeadressen

Start med en tunnel som allerede fører trafikk, og bekreft deretter at adressen du planlegger å publisere ligger innenfor det beskyttede området. På en ASA kommer området fra krypto-ACL-en eller fra rutene i en VTI, og det må dekke kildens virkelige adresse, ikke subnettet filialen bruker til administrasjon. En velger som bommer på kilden gir deg en tunnel som står, og en flyt som aldri kommer inn i den.

Bekreft det med tunnel-tellerne og rutetabellen før du rører oversettelsen. Hvis kilden ikke er nåbar fra huben gjennom tunnelen, kan ingenting lenger ned i denne listen reparere det.

Stopp her hvis det beskyttede området og kildeadressen ikke stemmer.

Kontroll 2: avgjør hvilken kilde filialen vil se

Filialen ser enten klientens opprinnelige adresse eller en oversatt, og det valget bestemmer returveien. Å bevare klientadressen leses renere i kildens logger, men da må filialen sende svar for offentlige klienter tilbake gjennom tunnelen; en vanlig standard internett-rute sender dem den andre veien, og tilkoblingen dør i én retning. Å oversette kilden til en adresse filialen allerede ruter over tunnelen fjerner det kravet.

Oversettelse endrer også hva kilden kan logge og hva kildebaserte regler kan matche. Hvis applikasjonen trenger å vite mennesket bak en forespørsel, hører det hjemme i en autentisert omvendt proxy, ikke i en NAT-beslutning.

Kontroll 3: skriv oversettelsen mot de virkelige grensesnittene

En ASA vurderer oversettelsesregler i rekkefølge og rapporterer hvilken som matchet, så grensesnittparet i regelen er ikke kosmetisk. En regel skrevet for en vei utenfra og inn vil ikke matche en flyt der inngang og utgang avviker fra dem du antok.

Veien du bygger har fire deler, og alle fire må stemme:

Behandle områdene i den tabellen som plassholdere. Det som betyr noe, er at tuppelen etter oversettelse er en adresse filialen godtar over tunnelen, og at den omvendte mappingen finnes i NAT-tilstanden slik at svaret gjenopprettes på vei ut.

Kontroll 4: begrens tilgangsregelen til den publiserte porten

Publiser porten, ikke verten. En regel som tillater kilden på hver tjeneste gjør én publisert applikasjon til en vei til alt kilden kjører, inkludert administrasjonsgrensesnittet du med vilje holdt utenfor internett. Tillat den publiserte porten fra den oversatte kilden til kilden, og la administrative tjenester bli på sin bare-VPN-vei.

Kontroller rekkefølgen på reglene samtidig. En bred tillatelse over din spesifikke regel gjør den spesifikke regelen usynlig.

Kontroll 5: spor én forespørsel og svaret på den

Ikke start med en nettleser, fordi en nettleser skjuler hvilken del som feilet. Spor flyten på huben og les resultatet før du endrer noe.

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

Sporet navngir oversettelsen som matchet, tilgangsregelen som tillot eller avviste flyten, og om pakken ble rutet inn i tunnelen. Hvis det viser flyten forlate et grensesnitt du ikke forventet, er grensesnittparet i NAT-regelen feil. Hvis det viser en avvisning, er rekkefølgen på reglene feil. Hvis den når tunnelen men kilden aldri svarer, er problemet returveien til filialen.

Send deretter én ekte forespørsel utenfra og bekreft at svaret kommer tilbake gjennom samme tunnel. Noter den publiserte oppføringen, oversettelsen, det beskyttede adresseparet og returruten som publiseringsrekorden.