: > alias ip-masq-21 ip_masq_ftp
: > alias ip-masq-* off
: >
: Right.
Someone else said we need 'ip-masq-tcp-21' rather than 'ip-masq-21', so we
can account for UDP packets. Also, how about IP masquerading support for
ICMP packets, although this might be a bit difficult to implement reliably.
One possible solution is to broadcast/multicast ICMP packets across the
network behind the firewall to all hosts that output ICMP packets. Another
possibility is to convert the current IP masquerading setup of a transparent
server-only implementation to a server/client implementation for packets
other than TCP and UDP packets, i.e. the host with the REAL IP address acts
as the server, and allows the 'clients' (which must be running the right
version of Linux) to directly send and receive packets from the server.
However, the second suggestion could lead to security problems if not done
properly (the IP masquerading server could be used from the outside Internet
to either a, gain access to the internal network, or b, 'resend' packets
to make the real originating host totally anonymous).
: Yes. You need to cache that. One kerneld request per masqueraded session
: makes no sense whatever. Besides, those IP packets are routed, thus you're
: in interrupt while you're doing this -> the kernel has to store the packet
: somewhere until it gets a reply. Tossing the packet and relying on the TCP
: retransmit is OK only if you have a cache and the socket isn't cached yet.
BUT, we _HAVE_ to have a different response from kerneld for 'alias xxx off'
than for a failed module load if we implement this, so that the kernel will
keep trying to load a module which is supposed to exist, but will not keep
making a kerneld request for modules which are specified as 'off'. But, in
order to account for the circumstance where 'kerneld' rereads its config
file, we need a kernel function to reset the cache, in case someone adds
another application entry, and restarts kerneld. (I don't know if kerneld
understands the SIGHUP signal to reread its config file yet, but if it doesn't,
it should).
On the other hand, the problem with routing is already showing itself in the
existing kernel code to handle dispatching kerneld route requests; even if the
route request is successful, the first packet never gets transmitted, instead
returning 'network unreachable'. Also, it may be useful to be able to add
entries to the routing table which will ALWAYS dispatch a kerneld
request-route; this would be useful for using request-route to set up
IP aliasing via request-route. However, this may bring problems of its own
(we may need to implement DEPENDENCIES into the mechanism...)
-- Tom Lees <tom@lpsg.demon.co.uk>Grabel's Law: 2 is not equal to 3 -- not even for large values of 2.