<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-7" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>on 01/07/2009 09:10 PM panagiotis takis_rs wrote the following:</tt>
<blockquote cite="mid:BAY111-W43ECA7FB88FDE265A86C2AC5DF0@phx.gbl"
 type="cite">
  <style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
} </style><tt><br>
Η θύρα είναι οκ νομίζω.Αλλού πρέπει να είναι το πρόβλημα.</tt></blockquote>
<tt>Τα απαραίτητα modules των iptables είναι φορτωμένα ή τουλάχιστον
compiled-in στον πυρήνα;<br>
(ip_conntrack, ip_conntrack_ftp, ip_nat_ftp, κλπ)<br>
<br>
CONFIG_IP_NF_FTP - This module is required if
you want to do connection tracking on FTP
connections. Since FTP connections are quite hard to
do connection tracking on in normal cases, conntrack needs a so called
helper;
this option compiles the helper. If you do not add this module you
won't be
able to FTP through a firewall or gateway properly.<br>
<br>
The FTP protocol first opens up a
single connection that is called the FTP control
session. When we issue commands through this session, other ports are
opened to carry the rest of the data related to that specific command.
These connections can be done in two ways, either actively or
passively.
When a connection is done actively, the FTP
client sends the server a port and IP address to connect to. After
this,
the FTP client opens up the port and the server
connects to that specified port from a random unprivileged port
(&gt;1024) and sends the data over it.<br>
</tt>
<p><tt> The problem here is that the firewall will not know about these
extra connections, since they were negotiated within the actual payload
of the protocol data. Because of this, the firewall will be unable to
know
that it should let the server connect to the client over these specific
ports. </tt></p>
<p><tt> The solution to this problem is to add a special helper to the
connection tracking module which will scan through the data in the
control
connection for specific syntaxes and information. When it runs into the
correct information, it will add that specific information as
RELATED and the server will be able to track the
connection, thanks to that RELATED entry. Consider the
following picture to understand the states when the
FTP server has made the connection back to the
client.<br>
</tt></p>
<p><tt>Passive FTP works the opposite way. The
FTP client tells the server that it wants some
specific data, upon which the server replies with an IP address to
connect to
and at what port. The client will, upon receipt of this data, connect
to that
specific port, from its own port 20(the FTP-data port), and get the
data in
question. If you have an FTP server behind your
firewall, you will in other words require this module in addition to
your
standard iptables modules to let clients on the Internet connect to the
FTP server properly. </tt></p>
<tt>Do note that connection tracking has nothing to do with
NAT, and hence you may require more modules if you
are NAT'ing connections as well. For example, if you were to want to
NAT and track FTP
connections, you would need the NAT module as well.
All NAT helpers starts with ip_nat_ and follow that
naming convention; so for example the FTP
NAT helper would be named
ip_nat_ftp and the IRC
module would be named ip_nat_irc. The conntrack
helpers follow the same naming convention, and hence the
IRC conntrack helper would be named
ip_conntrack_irc, while the
FTP conntrack helper would be named
ip_conntrack_ftp.<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="http://iptables-tutorial.frozentux.net/iptables-tutorial.html#COMPLEXPROTOCOLS">http://iptables-tutorial.frozentux.net/iptables-tutorial.html#COMPLEXPROTOCOLS</a><br>
<br>
<a class="moz-txt-link-freetext" href="http://iptables-tutorial.frozentux.net/iptables-tutorial.html">http://iptables-tutorial.frozentux.net/iptables-tutorial.html</a><br>
</tt>
</body>
</html>