📄 ch04s07.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0077)http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s07.html -->
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?><HTML
xmlns="http://www.w3.org/1999/xhtml"><HEAD><TITLE>4.7.燜irewalls and NAT</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"><LINK
href="ch04s07.files/terena.css" type=text/css rel=stylesheet>
<META content="MSHTML 6.00.2800.1106" name=GENERATOR><LINK
title="IP Telephony Cookbook" href="index.html" rel=home><LINK
title="Chapter 4. Setting up basic services" href="ch04.html"
rel=up><LINK title="4.6. Setting up SIP services" href="ch04s06.html"
rel=previous><LINK title="Chapter 5. Setting up Advanced Services"
href="ch05.html" rel=next><LINK title=Chapter 1. Introduction
href="ch01.html" rel=chapter><LINK
title="Chapter 2. Technology Background" href="ch02.html"
rel=chapter><LINK title="Chapter 3. IP Telephony Scenarios"
href="ch03.html" rel=chapter><LINK
title="Chapter 4. Setting up basic services" href="ch04.html"
rel=chapter><LINK title="Chapter 5. Setting up Advanced Services"
href="ch05.html" rel=chapter><LINK
title="Chapter 6. Setting up Value-Added Services" href="ch06.html"
rel=chapter><LINK title="Chapter 7. Global telephony integration"
href="ch07.html" rel=chapter><LINK
title="Chapter 8. Regulatory / Legal considerations" href="ch08.html"
rel=chapter><LINK title="Appendix A. European IP Telephony Projects"
href="apa.html" rel=appendix><LINK
title="Appendix B. IP Telephony Hardware/Software" href="apb.html"
rel=appendix><LINK title=Glossary href="go01.html" rel=glossary><LINK
title="4.7.1. Firewalls and IP telephony" href="ch04s07.html#d0e5067"
rel=subsection><LINK title="4.7.2. NAT and IP telephony"
href="ch04s07.html#d0e5088" rel=subsection><LINK title="4.7.3. SIP and NAT"
href="ch04s07.html#d0e5128" rel=subsection></HEAD>
<BODY>
<DIV class=navheader>
<TABLE width="100%" summary="Navigation header">
<TBODY>
<TR>
<TH align=middle colSpan=3>4.7. Firewalls and NAT</TH></TR>
<TR>
<TD align=left width="20%"><A accessKey=p
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch04s06.html">Prev</A> </TD>
<TH align=middle width="60%">Chapter 4. Setting up basic
services</TH>
<TD align=right width="20%"> <A accessKey=n
href="http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/main/ch05.html">Next</A></TD></TR></TBODY></TABLE></DIV>
<DIV class=sect1 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H2 class=title style="CLEAR: both"><A id=d0e5059>4.7. Firewalls and
NAT</H2></DIV></DIV>
<DIV></DIV>
<P>Firewalls and <I class=firstterm>Network Address Translation</I> (NAT) affect
IP telephony signaling protocols, making it impossible to call targets outside
the private or protected network. While often firewalls and NATs go hand in
hand, they impose two different problems which shall be described here.</P>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=d0e5067>4.7.1. Firewalls and IP
telephony</H3></DIV></DIV>
<DIV></DIV>
<P>Both <SPAN class=acronym>SIP</SPAN> and H.323 calls use a number of different
ports, out of which only the signaling ports are well defined - TCP port 1720
for H.323 and TCP port 5060 (early versions of SIP used 5060 UDP as well). To be
able to place and receive calls to/from outside the protected network opening
these ports is a minimal requirement.</P>
<P>After signaling has started, further channels are required. H.323 often uses
a separate TCP connection for capability exchange (H.245), which uses
dynamically assigned port numbers. Likewise the RTP media stream uses
dynamically assigned port numbers on each side. The only restriction that
applies to these ports is that they are in the port range > 1023.</P>
<P>As a result, a firewall protected IP telephony zone needs either a firewall
that does not protect ports > 1023 or a firewall that is <SPAN
class=emphasis><EM>IP telephony aware</EM></SPAN> - meaning that it monitors all
<SPAN class=acronym>SIP</SPAN> and H.323 messages in order to open and close the
required ports on the fly. A third alternative is to deploy an H.323 or <SPAN
class=acronym>SIP</SPAN> proxy outside the protected zone protected by the
firewall, perhaps in a DMZ, and configure the firewall to allow communication of
endpoints only with this proxy. This is a mid-level security approach, as it
permits the relatively safe communication between protected endpoints and a
trusted proxy server outside the firewall. This document does not intend to give
an overview of suitable firewall solutions, so when installing IP telephony
solutions ensure that your firewall supports it.</P></DIV>
<DIV class=sect2 lang=en>
<DIV class=titlepage>
<DIV>
<DIV>
<H3 class=title><A id=d0e5088>4.7.2. NAT and IP telephony</H3></DIV></DIV>
<DIV></DIV>
<P>Another problem occurs if your IP telephony zone resides in a private network
(no public IP addresses). <SPAN class=acronym>SIP</SPAN> and H.323 use TCP for
signaling, but the messages carried in the application layer contain IP
addresses that are not recognized by the NAT. In addition, the H.323 RAS channel
uses UDP for transport. This combination results in the following problems:</P>
<DIV class=orderedlist>
<OL type=1>
<LI><SPAN class=emphasis><EM>Registration:</EM></SPAN> Consider an endpoint
which lies inside a private network and registers at a public server. Without
being aware of the NAT it would try to register with its private IP address.
Eventually the server's reply would reach the endpoint, but no call that the
server tries to put through using the registered address will.
<LI><SPAN class=emphasis><EM>Call signaling:</EM></SPAN> Some call signaling
messages contain IP addresses that are necessary for subsequent communication,
e.g. the IP address (and port) to which media data shall be sent. Usually an
endpoint transmits its local (private) IP address causing the communication
partner to fail when trying to connect to that IP address.</LI></OL></DIV>
<P>One possible solution is the STUN protocol, defined in RFC 3489. An endpoint
implementing this protocol connects to a public STUN server to be informed of
his public IP address. The result of this query is used as the IP address to
register with at a remote server. While STUN seems to be more popular in the
<SPAN class=acronym>SIP</SPAN> world there is no H.323 endpoint that we are
aware of that supports this feature.</P>
<P>Another possibility is to use a router that is aware of IP telephony
protocols and rewrites the IP addresses within the application layer messages,
as they are routed. But this requires full decoding and encoding support for
<SPAN class=acronym>SIP</SPAN> and/or H.323, which is simple for the text-based
<SPAN class=acronym>SIP</SPAN> protocol but quite complex for the ASN.1-based
H.323 protocol. In addition, it is always possible that such a router might
remove all message content it does not understand, so that trying to transport
new protocol features through such a router may inexplicably fail. Such an IP
telephony router may come in the form of an application running on the NAT
router itself - like the <SPAN class=productname>OpenH323Proxy</SPAN>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -