Jail with public IP alias
frank2 at fjl.co.uk
Thu Aug 29 08:52:43 UTC 2013
On 29/08/2013 02:08, Alejandro Imass wrote:
> On Wed, Aug 28, 2013 at 4:11 PM, Frank Leonhardt <frank2 at fjl.co.uk> wrote:
>> On 28/08/2013 19:42, Patrick wrote:
>>> On Wed, Aug 28, 2013 at 7:25 AM, Alejandro Imass <aimass at yabarana.com>
>>>> On Wed, Aug 28, 2013 at 5:42 AM, Frank Leonhardt <frank2 at fjl.co.uk>
>> Sorry guys - I had not intention of upsetting the EzJail fan club!
> No worries there I just think it's an awesome tool. We used plain old
> jails before, and we even went through the "service jail" path once,
> but EzJail is a lot more than just lightweight easy-to-use jailing.
>> The fact remains that I've tried to recreate this problem on what comes to a
>> similar set-up, but without EzJail, and I can't. I've only tested it on
>> FreeBSD 8.2 so far, and I've only tested it from INSIDE a jail. I completely
>> understood what you were saying about it doing weird stuff outside a jail,
>> but my point is that this may or may not be related.
> Actually you can replicate it easily. Assign a number of IPs to any
> interface but that the interface has a default route. It will always
> use the "primary" or default IP on the other end. You can probably see
> this effect even on a private network provided all the aliases route
> through the same gateway. You will not be able to see this effect
> using aliases on the loopback AFAIK.
>> You don't say what version you're running. I can try and recreate it on
>> another version.
> It doesn't matter, it's a very basic network issue with aliases in
> FreeBSD, Linux and other OSs. Look here:
> I would like to know how people deal with this on FBSD
Okay, I'm trying here. I tried to recreate it thus:
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
inet xx.yy.41.196 netmask 0xffffffc0 broadcast xx.yy.41.255
inet xx.yy.41.197 netmask 0xffffffff broadcast xx.yy.41.197
inet xx.yy.41.198 netmask 0xffffffff broadcast xx.yy.41.198
inet xx.yy.41.199 netmask 0xffffffff broadcast xx.yy.41.199
inet xx.yy.41.200 netmask 0xffffffff broadcast xx.yy.41.200
inet xx.yy.41.201 netmask 0xffffffff broadcast xx.yy.41.201
inet xx.yy.41.202 netmask 0xffffffff broadcast xx.yy.41.202
inet xx.yy.41.203 netmask 0xffffffff broadcast xx.yy.41.203
inet xx2.yy2.76.62 netmask 0xffffffc0 broadcast xx2.yy2.76.63
inet xx.yy.41.207 netmask 0xffffffff broadcast xx.yy.41.207
inet xx.yy.41.206 netmask 0xffffffff broadcast xx.yy.41.206
media: Ethernet autoselect (100baseTX
b1# ssh -b xx.yy.41.197 b2 -l myname
Open new session and...
b1# ssh -b xx.yy.41.198 b2 -l myname
Open new session and...
b1# ssh -b xx.yy.41.199 b2 -l myname
An so on....
Then on b2:
b2# w -n
9:43AM up 803 days, 22:47, 5 users, load averages: 0.07, 0.06, 0.02
USER TTY FROM LOGIN@ IDLE WHAT
myname p0 ns0.domainname.org.uk 9:28AM 14 -csh (csh)
myname p1 ns1.domainname.net 9:29AM 14 -csh (csh)
myname p5 xx.yy.41.199 9:29AM 13 -csh (csh)
myname p6 xx.yy.41.201 9:30AM - w -n
myname p7 xx.yy.41.207 9:30AM 11 -csh (csh)
The only problem I can see there is that the -n option isn't working on
w! I'll look in to that. The reverse lookups match the IP addressed
dialled in on. b2 has the same sshd bound to all IP addresses,
incidentally. b1 has more than one interface, but all the IP addresses I
used are on the same one.
My guess, if you're not getting this, is that you're configuring the
aliases in a different way, so the output of ipconfig might help, even
if it just convinces me the netmask is correct and stops me worrying.
I've obviously obfuscated the first part of mine.
Or have I misunderstood the problem?
More information about the freebsd-questions