Date: Sat, 24 Dec 2016 01:15:35 -0500 (EST) From: doug@safeport.com To: Ernie Luzar <luzar722@gmail.com> Cc: byrnejb@harte-lyne.ca, freebsd-questions@freebsd.org Subject: Re: IP address assignments to jails using ezjail Message-ID: <alpine.BSF.2.20.1612240104500.77243@fledge.watson.org> In-Reply-To: <585DDBD9.1070207@gmail.com> References: <b6c71debe36b214c620d4027ce6bec31.squirrel@webmail.harte-lyne.ca> <alpine.BSF.2.20.1612231139220.77243@fledge.watson.org> <585DDBD9.1070207@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Dec 2016, Ernie Luzar wrote: > doug wrote: >> On Thu, 22 Dec 2016, James B. Byrne via freebsd-questions wrote: >> >>> When I created the new jail I used this invocation: >>> >>> ezjail-admin create -x hlldrupal 'lo1|127.0.1.1,vtnet0|192.168.216.196' >>> >>> Inside the host rc.conf I have this: >>> >>> # Cloned i/f and assigned ipv4 addr for jails >>> cloned_interfaces="lo1" # For shared jail configuration >>> >>> And ifconfig on the host shows this: >>> >>> vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >>> metric 0 mtu 1500 >>> options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE> >>> ether 00:a0:98:fa:aa:b6 >>> inet 216.185.71.16 netmask 0xffffff00 broadcast 216.185.71.255 >>> inet 192.168.216.16 netmask 0xffffff00 broadcast 192.168.216.255 >>> inet 192.168.216.196 netmask 0xffffffff broadcast 192.168.216.196 >>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >>> media: Ethernet 10Gbase-T <full-duplex> >>> status: active >>> . . . >>> lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >>> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> >>> inet 127.0.1.1 netmask 0xffffffff >>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> >>> groups: lo >>> >>> Inside the jail ifconfig shows this: >>> >>> vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >>> metric 0 mtu 1500 >>> options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE> >>> ether 00:a0:98:fa:aa:b6 >>> inet 192.168.216.196 netmask 0xffffffff broadcast 192.168.216.196 >>> media: Ethernet 10Gbase-T <full-duplex> >>> status: active >>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >>> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> >>> groups: lo >>> lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >>> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> >>> inet 127.0.1.1 netmask 0xffffffff >>> groups: lo >>> >>> >>> All this seems to be correct and yet I cannot seem to obtain an ssh >>> connection to or from the jailed instance. ubound is running in the >>> jail and seems to be working. At least host responds to queries. >>> >>> root@hlldrupal:~ # host sendmail.com >>> sendmail.com has address 209.246.26.25 >>> sendmail.com mail is handled by 10 mxa-00148501.gslb.pphosted.com. >>> sendmail.com mail is handled by 20 mx2.proofpoint.com. >>> sendmail.com mail is handled by 10 mxb-00148501.gslb.pphosted.com. >>> >>> pf is not running in the jail but sshd is: >>> >>> root@hlldrupal:~ # service sshd status >>> sshd is running as pid 81502. >>> >>> root@hlldrupal:~ # service pf status >>> Cannot 'status' pf. Set pf_enable to YES in /etc/rc.conf or use >>> 'onestatus' instead of 'status'. >>> root@hlldrupal:~ # service pf onestatus >>> pf.ko is not loaded >>> >>> >>> I note that the flag IFDISABLED is present on the host's lo1. Why? Is >>> this the source of the connectivity problem with the jail? If so then >>> why does the host commend work when executed within the jail? In any >>> case I can ping the jail from without: >>> >>> [root@vhost04 ~ (master *%)]# ping 192.168.216.196 >>> PING 192.168.216.196 (192.168.216.196) 56(84) bytes of data. >>> 64 bytes from 192.168.216.196: icmp_seq=1 ttl=64 time=0.647 ms >>> >>> I just cannot connect to that address via ssh from without nor can I >>> connect ssh to any address from within the jail. >>> >>> >> >> The handbook suggests that getting loopback traffic is a good thing. That >> said none of our production systems do this and a number of the jails use >> sshguard via inetd. One of the original jail developers did not have a >> handy answer as to why, or if, this is a must. That said, it can't hurt. >> >> As to pinging, the answer provided by some very helpful people here, is >> ping -S. This assumes /etc/sysctl.conf has >> 'security.jail.allow_raw_sockets=1' and /usr/local/etc/ezjail/jail-name >> has: >> >> export jail_`jail-name`_parameters="allow.raw_sockets=1" >> >> If you read the thread [anyone know what 'ping: sendto: Can't assign >> requested" means'] it documents my rather painful acquisition of this >> knowledge :) >> > > > In a jail by design default, ping is considered a security risk. jail(8) > disables it by default unless the variable allow.raw_sockets is included in > that jails definition statements. Using the sysctl method enables ping for > all jails running on the host. This is ok for testing, but should be turned > off for an production environment and should be mandatory disabled for any > jail accessible from the public network. > Read [man 8 jail] for details. > > I have not checked ezjail in the last 6 months which at that time it was > still using the rc.conf method of jail definitions. At jail start you see a > warning message to convert to jail.conf method. There has been talk that the > rc.conf method will be removed in 11.1 release or very soon after. > > I would not assume that ezjail being in the handbook is am recommend way to > go. Its just one of many jail command wrapper utilities. Like all ports > things change and the updating of the handbook documentation is not the > responsibility of the port maintainer so it becomes outdated and misleading. > You are not the first person to fall into this hole. There has been talk > about removing all port documentation from the handbook just for this reason. I only gave the ezjail setup because what was what was being used in the question. It should be pretty clear that whatever shell script is being to to help with jail management will have no impact on the interactions of the jail userland with the host kernel. The question was (as I understood it), ping ain't working. The answer to that seems to be 'ping -S' at least for some versions of FreeBSD. That was new info to me. The ssh portion of the problem is very different. If the host can ssh and the jail can not, that yet another problem that is likewise not related to jail management scripts.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1612240104500.77243>