[nos-bbs] HTTP server restriction maybe

[Barry Siegfried]

["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:

> 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...

And don't you also have a 44-net IP address on the Linux side of
the TUN device to JNOS?

> 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; ...

And doesn't "he" also have a 44-net IP address on the Linux side
of the TUN device to JNOS?

> 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).

Ok... I'm trying to learn your terminology.

> 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.

And how is the *IP routing* set up for that path?  :)

> A browser client on host A1 seeking the jnos http server on B1 creates
> a packet with FROM IP 192.168.1.32.

... going *to* where?  If you number your interfaces and do your IP
routing correctly, then that should NOT be the case.  If you are trying
to connect to the JNOS HTTP server on B1 at site A1, then the original
frame from A1 should be carrying the 44-net FROM IP address you have
assigned to the RF interface (or the TUN device if JNOS is involved
at A1 with transmitting the packet over the air).

> 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.

Theoretically, it should be neither.  The previous paragraph I wrote
above applies here too (with A1 and B1 reversed).  What you aren't
explaining is what O/S "sees" the ASY radio interfaces?  Linux?
Perhaps it is JNOS (is it even possible for JNOS to see a "real"
physical ASY interface on the machine)?

> 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....

Well it should be.  Why isn't it?  Maybe that is what you have to look
at.

> 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?

Oh.  You mean "private" IP addresses (not "privacy").  Yes, well you
aren't supposed to propagate a "private" IP address outside of its
own LAN and onto the "public" network.  I wouldn't call amateur packet
radio a "public" network, however.  But this shouldn't even be an
issue if what I understand from above is correct...

> > > 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].

Good!  So then the issue is not with the HTTP server not working over
the ASY interface at all (as the title of this thread originally implied).

> The solution is rejected because the model is only a (happy?) accident

Are we having fun yet?

> 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.

Ok, if you insist.

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

You should *never* need NAT over amateur packet radio.  Certainly not
if you assign IP addresses to your interfaces correctly and add the
appropriate IP routing to accommodate them.

> > 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.

Good luck!  Net/Rom, or even FlexNet might work that.  :)

> I agree with you that parallel paths seem not readily available to us
> yet.

Don't hold your breath.  :)

> 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.

Skip, I'm sorry to tell you that cutting and pasting other people's
configs are EXACTLY what gets most newbies into trouble and getting
other people involved anyway "to straighten out the mess".  You are
not the first person to try and do this with an "automated installation"
of one sort or another.  All very noble goals to get more people
"interested".  But it doesn't change the fact that every config is
unique and there is just no way around that.

Honestly, I think you are spinning your wheels with this idea of
creating a "one config fits all" scenario.  There are infinite
possibilities within infinite choices.  You MUST tailor your config
to your individual requirements and no "generally available" cut and
paste is ever going work very well at all.

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at k2mf.ampr.org         |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+