Publikigi internan servon tra ASA ejo-al-eja VPN

Publikigi servon, kiu vivas malantaŭ ejo-al-eja VPN, estas unu tasko kun kvin fiaskaj punktoj, kaj ili fiaskas en fiksa ordo. La tunelo leviĝas, la traduko kongruas, la filio respondas, kaj la respondo revenas laŭ la sama vojo. Kiam iu ajn el tiuj estas malĝusta, la retumilo montras la saman aferon: konekto, kiu pendas aŭ resetiĝas. Laboru la liston de supre malsupren kaj haltu ĉe la unua kontrolo, kiu fiaskas.

Kontrolo 1: la tunelo protektas la originan adreson

Komencu de tunelo, kiu jam pasigas trafikon, poste konfirmu, ke la adreso, kiun vi planas publikigi, kuŝas ene de la protektita gamo. Ĉe ASA tiu gamo venas de la kripta ACL aŭ de la itineroj de VTI, kaj ĝi devas kovri la veran adreson de la origino, ne la subreton, kiun la filio uzas por administrado. Selektilo, kiu maltrafas la originon, donas al vi tunelon, kiu staras, kaj fluon, kiu neniam eniras ĝin.

Konfirmu per la tunelaj nombriloj kaj la itinera tabelo antaŭ ol tuŝi la tradukon. Se la origino ne estas atingebla de la centro tra la tunelo, nenio pli poste en ĉi tiu listo povas ripari ĝin.

Haltu ĉi tie, se la protektita gamo kaj la origina adreso ne kongruas.

Kontrolo 2: decidu, kiun fonton la filio vidos

La filio vidas aŭ la originan klientan adreson aŭ tradukitan, kaj tiu elekto decidas la returnan vojon. Konservi la klientan adreson legiĝas pli pure en la protokoloj de la origino, sed tiam la filio devas sendi respondojn por publikaj klientoj reen tra la tunelo; ordinara interreta defaŭlta itinero sendas ilin la alian direkton kaj la konekto mortas en unu direkto. Traduki la fonton al adreso, kiun la filio jam enrutigas tra la tunelo, forigas tiun postulon.

Traduko ankaŭ ŝanĝas kion la origino povas protokoli kaj kun kio fontbazitaj reguloj povas kongrui. Se la aplikaĵo bezonas scii la homon malantaŭ peto, tio apartenas al aŭtentikigita inversa prokurilo, ne al decido pri NAT.

Kontrolo 3: skribu la tradukon laŭ la realaj interfacoj

ASA taksas tradukajn regulojn laŭ ordo kaj raportas, kiu kongruis, do la interfaca paro ene de la regulo ne estas kosmetika. Regulo skribita por vojo de ekstere al interne ne kongruos kun fluo, kies eniro kaj eliro diferencas de tiuj, kiujn vi supozis.

La vojo, kiun vi konstruas, havas kvar krurojn, kaj ĉiuj kvar devas kongrui:

Traktu la gamojn en tiu tabelo kiel lokokupilojn. Gravas, ke la opo post traduko estas adreso, kiun la filio akceptas tra la tunelo, kaj ke la inversa mapado ekzistas en la NAT-stato, por ke la respondo restariĝu survoje eksteren.

Kontrolo 4: limigu la alirregulon al la publikigita pordo

Publikigu la pordon, ne la gastiganton. Regulo, kiu permesas la originon ĉe ĉiu servo, transformas unu publikigitan aplikaĵon en vojon al ĉio, kion la origino funkciigas, inkluzive de la administra interfaco, kiun vi intence tenis ekster la interreto. Permesu la publikigitan pordon de la tradukita fonto al la origino, kaj lasu administrajn servojn sur ilia nur-VPNa vojo.

Kontrolu la regulan ordon samtempe. Larĝa permeso super via specifa regulo faras la specifan regulon nevidebla.

Kontrolo 5: spuru unu peton kaj ĝian respondon

Ne komencu per retumilo, ĉar retumilo kaŝas, kiu kruro fiaskis. Spuru la fluon ĉe la centro kaj legu la rezulton antaŭ ol vi ŝanĝos ion.

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

La spuro nomas la tradukon, kiu kongruis, la alirregulon, kiu permesis aŭ rifuzis la fluon, kaj ĉu la paketo estis enrutigita en la tunelon. Se ĝi montras la fluon eliri interfacon, kiun vi ne atendis, la interfaca paro en la NAT-regulo estas malĝusta. Se ĝi montras rifuzon, la regula ordo estas malĝusta. Se ĝi atingas la tunelon sed la origino neniam respondas, la problemo estas la returna vojo de la filio.

Poste sendu unu veran peton de ekstere kaj konfirmu, ke la respondo revenas tra la sama tunelo. Registru la publikigitan enskribon, la tradukon, la protektitan adresparon kaj la returnan itinero kiel la publikigan protokolon.