De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft NAT-gedrag (netwerkadresomzetting) in routers die werken als CUBE (Cisco Unified border-element), CME of CUCME (Cisco Unified Communications Manager Express), gateways en CUSP (Cisco Unified SIP proxy).
Cisco raadt kennis van de volgende onderwerpen aan:
De informatie in dit document is gebaseerd op
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Netwerkadresomzetting is een veelgebruikte techniek voor het vertalen van IP-adressen op pakketten die tussen netwerken stromen door gebruik te maken van verschillende adresruimtes. Het doel van dit document is niet om NAT te herzien. Dit document is eerder bedoeld om een uitgebreid overzicht van NAT te bieden zoals het wordt gebruikt in Cisco VoIP-netwerken. Bovendien is de reikwijdte beperkt tot componenten die deel uitmaken van de MS-Voice-technologie.
Afbeelding 1
Opmerking: het kan helpen om aan NAT te denken als een ondersteuning om IP-pakketten naar en uit netwerken te leiden met behulp van privé-adresruimte. Met andere woorden, NAT maakt niet-routable adressen routable
Figuur 2 toont de topologie die in de illustraties van verwijzingen wordt voorzien die volgen.
Afbeelding 2
Deze verklarende woordenlijst is fundamenteel om NAT te begrijpen en te beschrijven
Opmerking: Maak u op uw gemak met deze bepalingen. Alle notities of documenten op NAT kunnen hier zeker naar verwijzen
Dit is de eenvoudigste vorm van NAT, waar in elk binnenadres statisch wordt vertaald naar een buitenadres (en vice versa).
Afbeelding 3
De CLI naar configuratie voor de bovenstaande vertaling is als volgt
interface Ethernet0/0
IP-adres 10.1.1.3 255.255.255.0
IP NAT binnen
!
interface Serial0/0
IP-adres 200.1.1.251 255.255.255.252
ip Nat buiten <— Vereist![2]
ip Nat binnenbron statisch 10.1.1.2 200.1.1.2
ip Nat binnenbron statisch 10.1.1.1 200.1.1.1
In dynamische NAT, wordt elke binnengastheer in kaart gebracht aan een adres van een pool van adressen.
De volgende CLI illustreert het configureren van dynamische NAT
Wanneer de pool (van IP-adressen) kleiner is dan de set adressen die moeten worden vertaald, komt deze functie van pas.
Afbeelding 4 illustreert PAT.
Afbeelding 4
Cisco NAT-implementatie is zeer veelzijdig met een groot aantal opties. Een paar worden hieronder vermeld, maar gelieve te verwijzen naar http://www.cisco.com/en/US/partner/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html voor details op de volledige lijst van verbeteringen.
Een spelletje in NAT-taal verwijst naar de koppeling tussen de <host IP, port> en <global address, global port> tuples. Het staat het NAT apparaat toe om het aantal van de bestemmingshaven (dat de globale haven zou zijn) van inkomende berichten te gebruiken om de bestemming terug naar de gastheer IP en de haven in kaart te brengen die de zitting voortkwamen. Het is belangrijk om op te merken dat pinholes time-out na een periode van niet-gebruik en het publieke adres wordt teruggegeven aan de NAT pool.
Zo, wat zijn de kwesties en de zorgen met NAT in de netwerken van VoIP? Denk eraan dat NAT die we tot nu toe hebben besproken (losjes aangeduid als basis-NAT) alleen het IP-adres vertaalt in de IP-pakketheader en de controlesom herberekent, natuurlijk, maar VoIP-signalering bevat adressen die zijn ingebed in de kern van de signaleringsberichten. Met andere woorden, op Layer 5
Afbeelding 5 illustreert het effect van het niet-vertaald laten van de ingesloten IP-adressen. De vraag die signaleert voltooit succesvol, maar de proxy van SIP bij de dienstverlener ontbreekt het proberen om media (RTP) pakketten aan media adres te leiden dat door de call agent wordt verzonden!
Afbeelding 5
Een ander voorbeeld is het gebruik van Contact door SIP-endpoints: veld in SDP om het adres door te geven waar het eindpunt signaleringsberichten voor nieuwe verzoeken wil ontvangen.
Deze kwesties worden behandeld door een eigenschap genoemd Application Layer Gateway (ALG).
Een ALG begrijpt het protocol dat wordt gebruikt door de specifieke toepassingen die hij ondersteunt (bijv. SIP) en voert protocolpakketinspectie en "fixup" van verkeer door. Zie http://www.voip-info.org/wiki/view/Routers+SIP+ALG voor een goede beschrijving van de manier waarop de verschillende velden zijn ingesteld voor SIP-gesprekssignalering.
Op Cisco-routers is ondersteuning voor ALG SIP standaard ingeschakeld op de standaard TCP-poort 5060. Het is mogelijk om ALG te configureren om niet-standaard poorten voor SIP-signalering te ondersteunen. Raadpleeg http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-tcp-sip-alg.html.
Waarschuwing: Pas op! Er is geen RFC of andere standaard die aangeeft welke ingesloten velden vertaald moeten worden voor de verschillende VoIP protocollen. Als gevolg daarvan verschillen de implementaties van leverancier van apparatuur, wat leidt tot problemen met de interfaces (en TAC-cases).
Aangezien gateways per definitie geen ip-to-ip apparaten zijn, is NAT niet van toepassing.
Deze sectie van de de vraagscenario's van het documentoverzicht met CME om te begrijpen waarom NAT moet worden gebruikt.
Scenario 1. Lokale telefoons
Scenario 2. Externe telefoons (met openbare IP-adressen)
Scenario 3. telewerker op afstand
Opmerking: in alle gevallen moet het CME IP-adres routeerbaar zijn om audio te laten stromen
In dit scenario (Afbeelding 6) zijn de twee telefoons die bij de oproep betrokken zijn mager telefoons met privé IP-adressen.
Afbeelding 6
Opmerking: Onthoud dat mager telefoon die is aangesloten in een gesprek met een andere mager telefoon in hetzelfde CME-systeem zijn mediapakketten rechtstreeks naar de andere telefoon stuurt; D.w.z. RTP voor lokale telefoons naar lokale telefoons stroomt NIET door CME.
Daarom is NAT in dit geval niet van toepassing of vereist.
Opmerking: CME bepaalt of media (RTP) direct of niet gebaseerd moeten zijn op de vraag of de twee telefoons betrokken bij een oproep zowel mager zijn als in hetzelfde netwerksegment. Anders voegt CME zichzelf in het RTP-pad in.
In dit scenario (afbeelding 7) plaatst CME zichzelf in de RTP-stream zodat RTP van de telefoons op de CME wordt beëindigd. CME zal de stromen naar de andere telefoon opnieuw genereren. Aangezien CME zowel op het binnen (privé) netwerk als het buitennetwerk zit en zijn binnenadres naar de binnentelefoon en buiten (openbaar) adres naar de buitentelefoon verzendt, is NAT ook hier niet vereist.
Houd er echter rekening mee dat de UDP/TCP-poorten (zowel signalering als RTP) moeten zijn geopend tussen externe IP-telefoon en CME-bronIP-adres. Dit betekent dat de firewalls of andere filterapparaten zodanig zijn geconfigureerd dat de poorten in kwestie zijn toegestaan.
Afbeelding 7
Opmerking: Let op dat signalering [berichten] altijd worden beëindigd op CM
Dit verwijst naar IP-telefoons die via een WAN verbinding maken met CME ter ondersteuning van telewerkers met vestigingen die ver van de CME-router staan. De meest voorkomende ontwerpen zijn die waarbij telefoons met routeerbare IP-adressen en telefoons met privé IP-adressen betrokken zijn.
Als beide telefoons betrokken bij de vraag met openbare, routable IP adressen worden gevormd, kunnen de media rechtstreeks tussen de telefoons (figuur 8) stromen. Daarom opnieuw, geen behoefte aan NAT!
Afbeelding 8
In dit scenario wordt de oproep gesignaleerd tussen skinny telefoons geconfigureerd met privé IP-adressen. De routers van het huisbureau (SOHO), over het algemeen, neigen "SCCP bewust"te zijn. d.w.z. niet in staat om de in de SCCP-berichten ingesloten IP-adressen te vertalen. Dit betekent dat de telefoons op het moment dat de installatie is voltooid, eindigen met elkaars privé IP-adres. Aangezien beide telefoons privé zijn, zal CME de vraag tussen hen zo signaleren dat de audio direct tussen de telefoons stroomt. Dit zal echter resulteren in eenrichtings- of eenrichtingsaudio (aangezien privé IP-adressen per definitie niet op het internet kunnen worden gerouteerd!), tenzij een van de volgende tijdelijke oplossingen wordt geïmplementeerd-
· Statische routes op de SOHO-routers configureren
· een IPsec VPN-verbinding met de telefoons tot stand brengen
Een betere manier om dit op te lossen is het configureren van "mtp". Het mtp-bevel zorgt ervoor dat media (RTP)-pakketten van externe telefoons door de CME-router worden verzonden (afbeelding 9).
Afbeelding 9
De "mtp"oplossing is beter wegens complicaties met het openen van firewallhavens. De mediapakketten die via een WAN worden verzonden, kunnen door een firewall worden geblokkeerd. Dit betekent dat u poorten op de firewall moet openen, maar welke? Met CME die de audio aflost, kunnen de firewalls gemakkelijk worden gevormd om de pakketten over te gaan RTP. CME router gebruikt een specifieke UDP-poort (2000!) voor mediapakketten. Dus door pakketten toe te staan van en naar poort 2000 kan AL het RTP-verkeer worden doorgegeven.
Afbeelding 10 illustreert hoe u mtp kunt configureren.
Telefoon 1
mac 111.222.333
type 7965
mtp
knop 1:1
Afbeelding 10
Alles is niet geweldig met mtp. Er zijn situaties waarbij mtp niet gewenst is
Als u dus een WAN-configuratie hebt die multicast-pakketten kan doorsturen en u kunt RTP-pakketten via uw firewall toestaan, kunt u beslissen om MTP niet te gebruiken.
Merk op dat SIP telefoons niet werden genoemd in de bovenstaande scenario's. Dit komt door het feit dat als een van de telefoons een SIP-telefoon is, CME zichzelf invoegt in het audiopad. Dit wordt dan het lokaal-naar-externe scenario dat eerder wordt beschreven, waarbij NAT niet nodig is.
De CUBE voert inherent NAT- en PAT-functies uit aangezien alle sessies worden beëindigd en opnieuw gestart. De CUBE vervangt zijn eigen adres door het adres van elk eindpunt waarmee het communiceert, en verbergt (vertaalt) zo effectief het adres van dat eindpunt.
Zodoende is NAT niet vereist voor de CUBE-functie. Er is een VoIP-servicescenario waarin NAT op de CUBE is vereist, zoals in de volgende sectie wordt beschreven.
Een korte achtergrond bij Hosted Telephony Service helpt de beweegredenen voor deze functie te begrijpen.
Hosted telefhony Service is een nieuwe vorm van VoIP-service waarin het grootste deel van het tandwiel zich op de locatie van de dienstverlener bevindt. Ze werken met de thuisgateways (HGW), die alleen basis-NAT implementeren (bijv. NAT op L3/L4). Bijvoorbeeld Verizon installeert de Optical Network Terminal (ONT), die FiOS-diensten in huis verleent; spraakoproep wordt gesignaleerd met behulp van een SIP-proces dat in het ONT is ingebouwd. De SIP-signalering wordt via het private IP-netwerk van Verizon gemaakt voor nieuwe soft switches, die de service en controle leveren om spraakcommunicatie tot stand te brengen met andere klanten van de FiOS Digital Voice, of met traditionele telefoonklanten.
Tot de belangrijkste vereisten voor de gehoste telefoniedienst behoren onder meer:
Welke mogelijkheden zijn er, gezien het bovenstaande, om een dergelijke dienst te realiseren?
De NAT SBC-optie voldoet aan de bovenvermelde providervereisten.
De NAT SBC werkt als volgt (afbeelding 11)
Afbeelding 11
De voorbeeldconfiguratie voor een typische NAT SBC volgt.
IP NAT SIP-sbc
proxy 200.200.200.10 5060 15.3.33.22 5060 protocol udp
call-id-pool
sessie-time-out 300
modus toegestaan doorstroming
poort negeren
!
ip NAT-pool sbc1 15.3.33.61 15.3.33.69 netmasker 255.255.0.0
ip nat pool sbc2 15.3.33.91 15.3.33.99 netmasker 255.255.0.0
ip Nat pool call-id-pool 1.1.1.1 1.1.255.254 netmask 255.255.0.0
ip Nat buitenzwembad 200.200.200.100 200.200.200.200 netmask 255.255.255.0
IP NAT binnen bronlijst 1 pool sbc1 overload
IP NAT binnen bronlijst 2 pool sbc2
IP Nat buiten bronlijst 3 pool buiten-pool add-route
IP NAT binnen bronlijst 4 pool call-id-pool
!
toegangslijst 1 vergunning 10.1.1.0 0.0.0.255
toegangslijst 1 vergunning 171.1.1.0 0.0.0.255
toegangslijst 2 vergunning 20.1.1.0 0.0.0.255
toegangslijst 2-vergunning 172.1.1.0 0.0.0.255
toegangslijst 3-vergunning 15.4.0.0 0.0.255.255
toegangslijst 3-vergunning 15.5.0.0 0.0.255.255
toegangslijst 4 vergunning 10.1.0.0 0.0.255.255
toegangslijst 4 vergunning 20.1.0.0 0.0.255.255
Afbeelding 13 en afbeelding 14 illustreren de gespreksstroom in termen van de vertalingen. De volgende punten moeten worden opgemerkt:
— SIP-telefoon A - 15.3.3.62 2001
— SIP-telefoon B - 15.3.33.62 2002
Afbeelding 13
Afbeelding 14
In eerdere versies (van SBC NAT) moesten SIP-endpoints levensechte pakketten verzenden om de SIP-registratiepijp open te houden (zodat out->in het verkeer kan stromen, bijvoorbeeld inkomende gesprekken). bewaar-levendige pakketten konden elk SIP-pakket zijn dat door het eindpunt of de registratieserver (zachte switch) werd verzonden. Recente versies voorkomen dat dit nodig is, waarbij de NAT-SBC zelf (in tegenstelling tot zachte switches) de eindpunten dwingt om regelmatig opnieuw te registreren om de speldengaten open te houden.
Opmerking: Symptomen van een verlopen registratiepunt kunnen obscuur zijn, met willekeurige vraag signalering mislukkingen.
CUSP heeft de notie van een logisch netwerk, dat verwijst naar een verzameling van lokale interfaces die op dezelfde manier worden behandeld voor (bijv. interface, poort, transport voor het luisteren) routering doeleinden. Wanneer u een logisch netwerk configureert op CUSP, kunt u dit configureren om NAT te gebruiken. Na configuratie wordt SIP ALG automatisch ingeschakeld. Dit is nuttig bij bepaalde logische netwerken.
Een duidelijk symptoom zou kunnen zijn dat een vraag in één of beide richtingen ontbreekt. Minder duidelijke symptomen kunnen zijn:
Debug uitvoer voor een paar scenario's worden hieronder getoond. Ze zijn meestal voor zichzelf!
De configuratie en debug lijnen voor basisNAT worden hieronder getoond.
De uitvoerlijnen van debug ip Nat SIP worden weergegeven. In dit geval wordt het ingesloten IP-adres op een uitgaand pakket vertaald.
Overzicht:
VoIP en NAT
NAT-functiematrix
Hosted NAT-traject:
NAT SBC
ALG:
CME
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
23-May-2017 |
Eerste vrijgave |