can a domain name config point to a vlan tag at the host

Jon Radel jon at radel.com
Sat Aug 15 18:43:01 UTC 2020


On 8/15/20 13:19, Arthur Chance wrote:
>> Now last month a guy posted on the questions list that he was using vlan
>> tags to separate his single dynamic public ip address into 4 vlan tags.
>> One for the host and 3 for vnet jails. He states he can ping the public
>> internet from inside of the vnet jails using this concept.
> That is meaningless AFAIUI. IP addresses are at level 3 of the network
> stack, vlans are at level 2, so they don't mix. (Dan Kaminsky can
> probably do something weird with them, you do not want to go there for
> business purposes. Or sanity.) Also, being able to ping out simply
> requires NAT. Being able to receive incoming connections requires public
> IP addresses.

Welll.....with some risk of muddying the waters further, I'll point out
that inbound NAT does exist, especially the variant frequently referred
to as "port forwarding."  However, if I remember umpteen messages back
in this thread, one of Ernie's requirements is that he use the standard
ports for everything, so this would not solve his problem.  I do,
however, suspect, that earlier discussions revolving around making
something like this work probably involved this technique.

Ernie:

By this I mean, it is generally possible (by which I mean it is a
common, but not universal, feature), should one want to ssh from the
outside world into 3 virtual devices for which one has only private IP
addresses, to setup port forwarding, usually on your firewall or
whatever device is doing the rest of your NAT, along the lines of:

17.17.17.17:2022 ==> 192.168.1.2:22

17.17.17.17:2023 ==> 192.168.2.2:22

17.17.17.17:2024 ==> 192.168.3.2:22

So you simply tell the remote ssh client to connect to port 2022, 2023,
or 2024 depending on which virtual device you wish to connect to.  The
NAT device on the edge of your network then knows how to mangle the
address and port numbers in the headers and the packets can then be
routed properly on the internal network using the RFC 1918 addresses.

What is not available is to somehow map

17.17.17.17:22 ==> 192.168.1.2:22 or 192.168.2.2:22 or 192.168.3.2:22

mapping based on some value in DNS (layer 3 routing pays no attention to
DNS) or the application data (layer 3 routing pays no attention to the
contents of the payload). 

Unless of course (and this is a huge unless--of the "this way lies
madness" variety) you come up with your own variation on the ssh
protocol, write your own custom clients to use the new protocol, write
your own proxy to run at the edge of your network, etc., etc. 
Hmmmm....just thought of a way to do it with only a custom client in
order hide the different port numbers from the user.....   And then
repeat for every other protocol you wish to use.

In any case, all the regular ssh clients connect to a fixed address:port
combo.  The port defaults to 22.  A given address can have only one
thing listening on a given port.  Unless the protocol and server
themselves have some mechanism for multiplexing (eg HTTP & HTTPS) or
store & forward (SMTP), as has been discussed earlier in this thread, or
there is some type of whizz-bang proxy server that looks at the contents
of the application data and then establishes back-end network
connections based on that data (say a layer 7, HTTP/HTTPS load balancer
than assembles content from different back-end servers based on the
contents of the request string), there's no support unless you write
your own.

-- 
--Jon Radel
jon at radel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4177 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20200815/d926521c/attachment.bin>


More information about the freebsd-questions mailing list