[nos-bbs] HTTP server restriction maybe

[Barry Siegfried]

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

> I jumped the gun on this one - at least I included "maybe" in the
> title...

> On Mon, 2007-04-16 at 03:11 -0400, Barry Siegfried wrote:
>
> > ["(Skip) K8RRA" <k8rra at ameritech.net> wrote]:
> >
> > > We both fail to serve browsers at the other site across radio links.
> > > We are both successful with telnet to the other site over radio
> > > between jnos.
> >
> > I'm sorry but that makes no sense unless you are somehow blocking HTTP
> > (port 80) connections and not blocking telnet (port 23) connections
> > over the radio link.  Also, are you sure your HTTP client (presumably
> > a machine with an operating system that supports a web browser) is
> > using the radio link to communicate to the HTTP server?
>
> When I responded to Maiko, you note I suspected asymmetrical routing?

I believe I did, yes.

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

> I suspect there are few solutions.

There are *always* at least a few solutions.

> The one that pops into mind is to extend the 44... network beyond
> the jnos stack back into the LAN.
>
> Except that violates other "rules"?

What "rules" does that violate?

> > > NO NAT may be the entire answer in a nutshell?
> >
> > Doubtful.
>
> You are right from the "many ways to skin a cat" perspective, maybe
> you even taught me that before today...

I did?

> My existing "problem" is lack of solution.  Each alternative I know
> messes up somebody somewhere it seems.

This is ALWAYS the case.  MOST of the time you can't do *anything*
without it affecting *something* else.  It's the nature of the beast.

> The missing NAT seems elegant...

How?

> > > The trace would be helpful of course :-)
> >
> > A trace is always helpful.
>
> Postmortems are enhanced for sure.

For sure!

> > > What are the chances I can install NAT as a service from the opsys
> > > on jnos?
> >
> > Very low.

If I even knew what an "opsys" was I might add.  :)

> > > Need to learn C first?
> >
> > Yes.  You would have to either lift or write 'C' code for insertion
> > into ip_route() (IPROUTE.C) that implements several things in order
> > to make IPNAT (for outgoing frames) and IP forwarding (for incoming
> > frames) work.  There was a time when you might have had to do that
> > in order to do what you want with JNOS over the internet (Linux was
> > the first O/S to have IPNAT capabilities in the mid-1990s).  Then
> > one or two lunatics wrote IPNAT and IP forwarding code for some
> > "specialty" NOSs in order to make them mimic what Linux does.  Then
> > after that, we became a dynamically IP-assigned world and IPNAT
> > appeared in Windows for the masses.
> >
> > But with small consumer DHCP/PPPoE/IPNAT routers today, why would
> > you want (or need) to do that anymore?  These routers handle these
> > functions very nicely now leaving your JNOS program to be very happy
> > running behind them.
> >
> > > Or am I being erratic?
> >
> > Possibly.
>
> OK - I can accept that, then let me ask your opinion of this:

Be careful to accept any "advice" from me.  I am considered to be
a lunatic by most commonly accepted definitions of what constitutes
one, particularly with my fascination about DOS and DOS NOS.  I am
never too far from a DOS machine.  You can take *that* to the bank!
:)

> IP Masquerade is a kernel function used routinely on those "old"
> machines serving as gateway in their second life.  They sit in a
> corner with gateway to internet

I presume by that you mean that a big Linux computer from yesterday
serves the function of a small router today.  Yes indeed!  No doubt
there are still setups like that from the days before small routers
existed!  And why not?  If it ain't broke...

> and sometimes a squid proxy to cache frequent pages.

I don't know what squid is, but that's ok.

> No "C" required - configure it into the kernel and add the external
> configuration to install it.

Yes of course.  The IP masquerade code already exists in a source
module that is available as a compile-time option or in a binary
module that is available as a link-time option.  Either way, you
just check a box and do your new build and you magically have
IP masquerade available in your Linux kernel.  The problem with
doing that for JNOS is that neither the IP masquerade code nor the
hooks into ip_route() exist yet.

> Might IP Masquerade be configured to work in the Linux host stack on
> the tun device traffic?

If my understand of Linux is correct, yes, you might be able to do this.
The question is, do you really want to do this?  The choice is yours.
Remember, of course, that IPNAT (or IP masquerade) works on outbound
*client* connections only.  It will not make services in your JNOS
program any more reachable from the internet than they were before
you started using IP masquerade.  To do *that* you would need to use
the "IP forward"ing feature of Linux, which we know as "port forwarding"
in today's small routers.

> Certainly that is the point you want to place the 44... static network
> (masqueraded) bridge to the "any IP" LAN network.  Even if the Linux
> host has no network beyond it, the host stack is a "foreign IP" as far
> as jnos is concerned and the host stands to gain "visibility" from the
> 44... network.

I'm sorry but you lost me on that statement.  :(

> There may be a significant difference between an eth0 device and a tun
> device, but the network location seems correct.

I don't know jack about Linux, but they are both "devices" (interfaces)
so they function identically with respect to how devices (interfaces)
"function".  But they *are* different in the sense that Ethernet devices
are "real" and Tunnel devices are "virtual".  Does that help?

> And if not IP Masquerade, then there are other options than writing
> it all over again?

I'm sorry but I don't understand the question.  I don't think I fully
understand what it is you are trying to do or accomplish.  If this is
all about an HTTP connection in JNOS that won't answer back out the
radio, then add an IP route into JNOS that will make it answer back
out the radio.

Does that help?

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