Publisere ei intern teneste over ein ASA-site-til-site-VPN

Å publisere ei teneste som lever bak ein site-til-site-VPN er éi oppgåve med fem feilpunkt, og dei feilar i fast rekkjefølgje. Tunnelen kjem opp, omsetjinga stemmer, filialen svarar, og svaret kjem tilbake same veg. Når noko av dette er feil, viser nettlesaren det same: ei tilkopling som heng eller blir tilbakestilt. Arbeid deg gjennom lista ovanfrå og ned og stopp ved den første kontrollen som feilar.

Kontroll 1: tunnelen vernar kjeldeadressa

Start med ein tunnel som allereie fører trafikk, og stadfest deretter at adressa du planlegg å publisere ligg innanfor det verna området. På ein ASA kjem området frå krypto-ACL-en eller frå rutene i ein VTI, og det må dekkje den verkelege adressa til kjelda, ikkje subnettet filialen brukar til administrasjon. Ein veljar som bommar på kjelda gjev deg ein tunnel som står, og ein flyt som aldri kjem inn i han.

Stadfest det med tunnelteljarane og rutetabellen før du rører omsetjinga. Viss kjelda ikkje er nåbar frå huben gjennom tunnelen, kan ingenting lenger nede i denne lista reparere det.

Stopp her viss det verna området og kjeldeadressa ikkje stemmer.

Kontroll 2: avgjer kva kjelde filialen vil sjå

Filialen ser anten den opphavlege klientadressa eller ei omsett, og det valet avgjer returvegen. Å ta vare på klientadressa les reinare i loggane til kjelda, men då må filialen sende svar for offentlege klientar tilbake gjennom tunnelen; ein vanleg standard internett-rute sender dei den andre vegen, og tilkoplinga døyr i éi retning. Å omsetje kjelda til ei adresse filialen allereie ruter over tunnelen fjernar det kravet.

Omsetjing endrar òg kva kjelda kan logge og kva kjeldebaserte reglar kan matche. Viss applikasjonen treng å vite mennesket bak ein førespurnad, høyrer det heime i ein autentisert omvend proxy, ikkje i ei NAT-avgjerd.

Kontroll 3: skriv omsetjinga mot dei verkelege grensesnitta

Ein ASA vurderer omsetjingsreglar i rekkjefølgje og rapporterer kva for ein som matcha, så grensesnittparet i regelen er ikkje kosmetisk. Ein regel skriven for ein veg utanfrå og inn vil ikkje matche ein flyt der inngang og utgang avvik frå dei du antok.

Vegen du byggjer har fire delar, og alle fire må stemme:

Behandle områda i den tabellen som plasshaldarar. Det som tel, er at tuppelen etter omsetjing er ei adresse filialen godtek over tunnelen, og at den omvende mappinga finst i NAT-tilstanden slik at svaret blir gjenoppretta på veg ut.

Kontroll 4: avgrens tilgangsregelen til den publiserte porten

Publiser porten, ikkje verten. Ein regel som tillèt kjelda på kvar teneste gjer éin publisert applikasjon til ein veg til alt kjelda køyrer, inkludert administrasjonsgrensesnittet du med vilje heldt utanfor internett. Tillat den publiserte porten frå den omsette kjelda til kjelda, og la administrative tenester bli på sin berre-VPN-veg.

Kontroller rekkjefølgja på reglane samstundes. Ei brei tillating over den spesifikke regelen din gjer den spesifikke regelen usynleg.

Kontroll 5: spor éin førespurnad og svaret på han

Ikkje start med ein nettlesar, fordi ein nettlesar skjuler kva del som feila. Spor flyten på huben og les resultatet før du endrar noko.

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 namngjev omsetjinga som matcha, tilgangsregelen som tillét eller avviste flyten, og om pakken vart ruta inn i tunnelen. Viss det viser flyten forlète eit grensesnitt du ikkje forventa, er grensesnittparet i NAT-regelen feil. Viss det viser ei avvising, er rekkjefølgja på reglane feil. Viss han når tunnelen men kjelda aldri svarar, er problemet returvegen til filialen.

Send deretter éin ekte førespurnad utanfrå og stadfest at svaret kjem tilbake gjennom same tunnel. Noter den publiserte oppføringa, omsetjinga, det verna adresseparet og returruta som publiseringsrekorden.