There is another technique for doing AFS clients behind the NAT
which seem to works in our environment.
RHEL3 (SL3 in really) on the NAT (unpatched), iptables with
SNAT/DNAT rules for every clients like this:
-A POSTROUTING -p udp -s 10.233.64.25 --sport 7001 -o eth0 \
-j SNAT --to-source a.b.c.d:17025
-A PREROUTING -p udp -d a.b.c.d --dport 17025 -i eth0 \
-j DNAT --to-destination 10.233.64.25:7001
a.b.c.d and eth0 are IP and ethernet device routed to the word (AFS
servers) on the NAT;
10.233.64.25 and 17025 are client's IP and static port for this particular
client.
AFS client works on the NAT server too w/o problem. All clients booted
via dhcp w/ static IP.
Some times file server will complane like this:
...... ProbeUuid failed for host a.b.c.d:17025
at the time when client booted after long time but other than that
AFS stay online after reboots.
On Wed, 25 May 2005, Niklas Edmundsson wrote:
> On Wed, 25 May 2005, Jim Rees wrote:
>
> > * Having the NAT machine being a NAT machine ONLY, WITHOUT an AFS
> > client/server/etc. If you as much as breath "afs" on the NAT box it
> > breaks.
> >
> > I run an OpenAFS client on my OpenBSD nat box with no problems. I did not
> > have to do anything special to make this work.
>
> For us, running an AFS client on our Linux NAT box works, but it means
> that AFS on the machines behind the NAT stops working.
>
> > * Rebooting the NAT box usually means restarting AFS on all clients as
> > the udp forwarding is lost.
> >
> > The clients will eventually recover without restarting. You can speed the
> > recovery with "fs checks -all".
>
> We've had incidents where fs checks -all didn't help (or seemed to
> help, but didn't), so I wouldn't bet money on it working everytime ;)
>
> /Nikke
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
> ---------------------------------------------------------------------------
> --- There's ALWAYS one more bug! ---
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> _______________________________________________
> OpenAFS-devel mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
Best regards,
Valery Mitsyn
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
