[nos-bbs] HTTP server restriction maybe

[(Skip) K8RRA]

On Mon, 2007-04-16 at 21:02 -0400, Barry Siegfried wrote:

> ["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:
> 
> > OK Barry - I believe I better understand / here is a little
> > clarification for you...
> >
> > On Mon, 2007-04-16 at 09:15 -0500, Barry Siegfried wrote:
> >
> > > ["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:
> > >
> > > > It is exactly what happened on my site.
> > > >
> > > > The http query arrived on asy from the radio and the server response
> > > > departed tun on it's way into cyberspace.
> > >
> > > Why is that?  Why could not the return path from the web server
> > > to the browsing client be via the radio?
> >
> > Routing...
> >
> > The request came from 66... (not 44...)
> 
> So you're saying the client request came in over the internet?
> I'm confused here.
> 
> > The remote browser [and mine is similar] is serviced by the host
> > stack (66...), not the jnos stack (44...).
> 
> What is a "host" stack?  By "host" do you mean Linux... with a TUN
> device to a JNOS program?  And whose JNOS stack?  Again I am quite
> confused.

Try this model:
Site A (me):
   Host A1 / Linux: static 192.168.1.32 IP + jnos 44.102.132.20 
   LAN to Internet bridge appliance: LAN IP 192.168.1.254 + WAN IP 24...
dynamic
   Host A2 / any O/S: dynamic LAN IP 192...
Site B (him):
   Host B1 / Linux: resident Internet bridge 66... dynamic IP eth0, +
static 192...? ip eth1, + jnos 44.102.132.42
   Host B2 / any O/S; ...

Both hosts A1 and B1 have two network stacks resident on them - a host
stack and a jnos stack (total: four stacks in the model).
Both jnos A and jnos B have httpd server "on".
The path A to B is restricted to radio - no path is developed via
Internet.

A browser client on host A1 seeking the jnos http server on B1 creates a
packet with FROM IP 192.168.1.32.
A browser client on host B1 seeking the jnos http server on A1 creates a
packet with FROM IP 66...
It is my presumption that the B1 packet gets FROM IP 66... by virtue of
interface assignment order during boot.  The B1 packet FROM IP 192...?
could also be valid but has not been seen.

HOWEVER:!
Remember that the choice of IP 66... or 192... for the FROM IP is a
secondary issue - the primary issue is that the FROM IP is NOT 44....
When I attempt to access the jnos http server B from host A1 or A2, I
become dead meat because my private C IP does not propagate over the
44... network.  That's the "rule" about privacy - right?

> 
> > So the FROM IP is a 66... address.  My jnos can't legit route IP 66...
> > out the radio.
> 
> Why not?  Where in the rules does it say you can't do that?

OK - strictly speaking with the above model I CAN [and I DID only to
prove a point].
The solution is rejected because the model is only a (happy?) accident -
the Site A portion of the model is my "norm",
AND the rule about *private subnet* prevents success at routing site A
client requests over network 44... to remote servers.

So far - only NAT seems to offer a solution - and NAT is not in use yet
in the amateur context?


> 
> Ok.  Then is what you need dynamic IP *routing* in JNOS so that it
> can detect a downed RF path and switch to the internet automagically?
> To the best of my knowledge nobody has yet ported BGP to any NOS.

You bring up a related subject for me in that question.
In the future I would like to believe I could define two paths from my
LAN to remote locations for redundancy.
I agree with you that parallel paths seem not readily available to us
yet.

As a parting thought Barry;
Remember this conversation is pointed at defining a *representative* set
of configuration examples for documentation on the wiki.  It is my
desire that the wiki example might be used like a cut-and-paste to
create new config files while changing a site.

73
de [George (Skip) VerDuin] K8RRA k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20070417/80c228e1/attachment.html>