[OpenAFS-devel] nat mode

Roland Kuhn rkuhn@e18.physik.tu-muenchen.de
Thu, 16 Feb 2006 14:38:32 +0100


--Apple-Mail-26-728639620
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi Jeffrey!

On 16 Feb 2006, at 14:26, Jeffrey Altman wrote:

> Roland Kuhn wrote:
>> Hi Jeff!
>
>> It seems like this UDP-based NAT has a lot more problems than I was
>> aware of. If the firewall were to do NAT based on the RX connections
>> instead, would that work? What I have in mind is a scheme where a
>> (potentially large) number of clients are behind a firewall which  
>> looks
>> to a server like a single client with very many open RX  
>> connections, all
>> on port 7001. Are there limitations? Does anybody know of a RX-aware
>> connection tracking code?
>>
>> Ciao,
>>                     Roland
>
> RX connections are very short lived.   Much shorter than the  
> lifetime of
> callbacks.  You need the server to be able to track a particular  
> client
> across multiple RX connections including ones established by the  
> server
> in order that callback breaks can be delivered.
>
> The server tracks clients by a combination of source address/port and
> UUID (if the client supports it).
>
> While I could conceive of a way of allowing a firewall to maintain its
> own RX connection to client mappings, the bigger problem from the
> perspective of the server is that the server would not be able to
> effectively distinguish the clients.  If two callbacks were requested
> for the same object by two clients without UUID support, the file
> server would only record one of them.   The callback break would be
> delivered to one client and not the other.  Of course, this is exactly
> the problem we have today.  So adding another layer does not solve
> anything.  The 1.4.1-rc7 file server already has the necessary code to
> do the right thing as do all 1.4 clients.
>
> Now we just have to wait while people upgrade.  A slow and painful
> process but its the only one we have.
>
> Jeffrey Altman

Thanks very much for this explanation. So now I just have to convince  
several big computing centers to upgrade their servers :-)

Ciao,
                     Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
	-Doug Gwyn
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------





--Apple-Mail-26-728639620
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFD9IBdI4MWO8QIRP0RAs/SAJ0S2825lxM/f9aqADTh8Ix38fQL6ACfc34E
R4y8F2jx4pXiNg2nOyH8z4Y=
=lp9o
-----END PGP SIGNATURE-----

--Apple-Mail-26-728639620--