DNS Doctoring on Asa Configuration eksempel

introduktion

dette dokument viser, hvordan DNS Doctoring bruges på Adaptive Security Appliance (ASA) til at ændre de indlejrede IP-adresser i Domain Name System (DNS) svar, så klienter kan oprette forbindelse til den korrekte IP-adresse på servere.

forudsætninger

krav

DNS Doctoring kræver konfiguration af Netværksadresseoversættelse (NAT) på ASA samt aktivering af DNS-inspektionen.

anvendte komponenter

oplysningerne i dette dokument er baseret på det Adaptive sikkerhedsapparat.

oplysningerne i dette dokument blev oprettet fra enhederne i et specifikt laboratoriemiljø. Alle de enheder, der blev brugt i dette dokument, startede med en ryddet (standard) konfiguration. Hvis dit netværk er live, skal du sørge for, at du forstår den potentielle indvirkning af enhver kommando.

konventioner

se Cisco tekniske Tips konventioner for mere information om dokument konventioner.

DNS Doctoring eksempler

DNS-Server på indersiden af ASA

Figur 1

nat (inside,outside) source static 10.1.1.100 198.51.100.100 dns!policy-map global_policy class inspection_default inspect dns

i Figur 1 styres DNS-serveren af den lokale administrator. DNS-serveren skal uddele en privat IP-adresse, som er den rigtige IP-adresse, der er tildelt applikationsserveren. Dette gør det muligt for den lokale klient at oprette forbindelse direkte til applikationsserveren.

desværre kan fjernklienten ikke få adgang til applikationsserveren med den private adresse. Som et resultat konfigureres DNS Doctoring på ASA til at ændre den indlejrede IP-adresse i DNS-responspakken. Dette sikrer, at når fjernklienten fremsætter en DNS-anmodning om www.abc.com, svaret, de får, er for den oversatte adresse på applikationsserveren. Uden DNS-nøgleordet på NAT-erklæringen forsøger fjernklienten at oprette forbindelse til 10.1.1.100, hvilket ikke fungerer, fordi denne adresse ikke kan dirigeres på internettet.

DNS-Server på ydersiden af Asa

figur 2

nat (inside,outside) source static 10.1.1.100 198.51.100.100 dns!policy-map global_policy class inspection_default inspect dns

i figur 2 styres DNS-serveren af internetudbyderen eller lignende tjenesteudbyder. DNS-serveren skal uddele den offentlige IP-adresse, Det vil sige den oversatte IP-adresse på applikationsserveren. Dette giver alle internetbrugere adgang til applikationsserveren via Internettet.

desværre kan den lokale klient ikke få adgang til applikationsserveren med den offentlige adresse. Som et resultat konfigureres DNS Doctoring på ASA til at ændre den indlejrede IP-adresse i DNS-responspakken. Dette sikrer, at når den lokale klient fremsætter en DNS-anmodning om www.abc.com, det modtagne svar er den rigtige adresse på applikationsserveren. Uden DNS-nøgleordet på NAT-erklæringen forsøger den lokale klient at oprette forbindelse til 198.51.100.100. Dette virker ikke, fordi denne pakke sendes til ASA, som taber pakken.

VPN NAT og DNS Doctoring

figur 3

overvej en situation, hvor der er netværk, der overlapper hinanden. I denne tilstand bor adressen 10.1.1.100 på både fjernsiden og den lokale side. Som følge heraf skal du udføre NAT på den lokale server, så fjernklienten stadig kan få adgang til den med IP-adressen 192.1.1.100. For at få dette til at fungere korrekt, er DNS Doctoring påkrævet.

DNS-Doctoring kan ikke udføres i denne funktion. DNS-nøgleordet kan kun føjes til slutningen af et objekt NAT eller kilde NAT. Den to gange nat understøtter ikke DNS-nøgleordet. Der er to mulige konfigurationer, og begge mislykkes.

Mislykket Konfiguration 1: Hvis du konfigurerer bundlinjen, oversætter den 10.1.1.1 til 192.1.1.1, ikke kun for fjernklienten, men for alle på internettet. Siden 192.1.1.1 er ikke internet routable, ingen på internettet kan få adgang til den lokale server.

nat (inside,outside) source static 10.1.1.100 192.168.1.100 dnsnat (inside,outside) source static 10.1.1.100 192.168.1.100 destination REMOTE_CLIENT REMOTE_CLIENT

mislykket konfiguration 2: Hvis du konfigurerer DNS Doctoring NAT-linjen efter den nødvendige NAT-linje to gange, forårsager dette en situation, hvor DNS-Doctoring aldrig fungerer. Som et resultat forsøger fjernklienten at få adgang til www.abc.com med IP-adressen 10.1.1.100, som ikke virker.