ASA: VPN-pordo kaj statika DMZ-PAT sur unu publika IP

Du servoj, unu publika adreso kaj DNS-nomo, kiu ŝajnas rezervi pordon. Ĝi ne faras. Antaŭ ol vi publikigos DMZ-servilon apud la VPN-enskribo sur ASA, skribu la enskribajn opojn kaj kontrolu ilin laŭvice; la unua kampo, kiu kongruas kun ekzistanta servo, estas la loko, kie la plano haltas. Ĉio sube supozas, ke la VPN finiĝas sur la aparato mem, ne sur interna servilo.

Skribu la kvin kampojn antaŭ ol skribi la komandon

Por ĉiu publika enskribo, notu la adresan familion, la publikan adreson, la transporton, la publikan pordon kaj la posedanton. La posedanto estas aŭ ASA-loka servo aŭ tradukita interna servilo. Du enskriboj povas kunhavi adreson kaj tamen esti malsamaj opoj, kaj du enskriboj povas aspekti malsamaj en diagramo dum ili kolizias sur la aparato.

Tenu duan kolumnon por la reala pordo, tiu, sur kiu la interna servilo fakte aŭskultas. La publika pordo kaj la reala pordo estas sendependaj elektoj, kaj en la momento, kiam vi kunfandas ilin en unu kolumnon, vi perdas la kapablon legi vian propran tradukon poste.

Legu la realajn kaj mapitajn poziciojn ĝuste

Komencu de la opo, kiun vi jam havas, ne de la servilo, kiun vi volas aldoni. Ilustra divido tenas la aprobitan VPN-enskribon sur publika TCP 443 kaj publikigas DMZ HTTPS-servilon sur publika TCP 8443, dum tiu servilo daŭre aŭskultas sur 443:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

En la elfalita komando, la reala servo kaj la mapita servo staras en fiksaj pozicioj, kaj ilia inversigo priskribas alian mapadon ol rompitan. Tio estas la plej ofta maniero, kiel funkcianta traduko fariĝas enigmo: la agordo validas, ĝi simple montras aliloken.

La gvidilo pri NAT de ASA 9.16 de Cisco dokumentas statikan PAT, la uzon de interfaca adreso kaj la signifojn de reala kontraŭ mapita pordo. Legu la sekcion por la eldono, kiun vi efektive ruligas; komando memorita de pli malnova platformo ne estas kompleta nuna agordo.

Kalkulu transporton kiel parton de la rezervo

TCP 443 kaj UDP 443 estas malsamaj opoj, kaj tiu diferenco ne donas al vi la UDP senpage. VPN povas havi apartajn TLS- kaj DTLS-aŭskultantojn, kaj aliaj agorditaj servoj eble jam tenas la transporton, kiun vi volas. Inventaru la efektivajn aŭskultantojn kaj la aliro-politikon anstataŭ supozi, ke la retpaĝo estas la tuta VPN-enskribo.

Dua gastignomo, kiu solviĝas al la sama adreso, ankaŭ ne solvas kolizion je transporta nivelo. DNS estas mapado de nomo al adreso, ne porda makleristo, kaj publikigi servilon per PAT ne estas la sama operacio kiel movi la VPN-aŭskultanton al alia pordo.

Se la VPN-enskribo vere devas moviĝi, kvar aferoj ŝanĝiĝas kune: la klienta profilo, la publika URL, la supra filtrado kaj ĉiu transporto, kiun la deplojo uzas. Faru ilin en unu fenestro anstataŭ unu post la alia. Tenu apartan administran vojon al la aparato malfermita antaŭ ol vi tuŝos la servon, kiun vi uzas por atingi ĝin. Sen dua vojo, la movo estas ŝanĝo, kiun vi ne povas malfari de ekstere.

Kontrolu de ekstere per novaj konektoj

Permesu nur la celitan DMZ-aplikaĵon sub la efektiva aliro-politiko, poste kontrolu la kongruan tradukan ordon, la revenan vojon de la servilo kaj la gastignomon sur la atestilo. PAT ŝanĝas la retan celon; ĝi ne donas aplikaĵan aliron kaj ne riparas atestilon, kiu nomas alian gastiganton.

Testu ambaŭ servojn per novaj konektoj de rajtigita ekstera gastiganto: la VPN devus ankoraŭ establiĝi, kaj la DMZ-peto devus atingi sian celitan aŭskultanton. Establita sesio povas teni antaŭan staton, do ĝi pruvas nenion pri mapado, kiun vi ŝanĝis antaŭ unu minuto.

Fermu la ciklon ĝisdatigante la enskriban inventaron per tio, kion vi deplojis, inkluzive de ĉiu aŭskultanto, kiun vi malkovris anstataŭ kreis. La sekva persono, kiu publikigos servon sur tiu adreso, komencos de via tabelo, kaj malĝusta vico tie kostas pli ol malĝusta komando ĉi tie.