From: Brandon Hoult (BrandonHoult_at_netscape.net)
Date: Mon 03 Feb 2003 - 18:28:26 GMT
Well, I thought it would be nice to understand the cause of this
problem, but I needed to get it working so I got the latest versions of
everything and rebuilt the kernel installed the latest vserver (it seems
to be in debian apt now, so I used that). Now have kernel 2.4.20ctx-16
vserver 0.22-4 and I still have exactly the same problem. Any other ideas?
Brandon.
Brandon Hoult wrote:
> *The terminology here is kind of confusing... maybe this will make it
> less ambiguous:
> <external> = another machine on the network
> <host> = the machine that hosts the vserver
> <vserver> = the virtual server running on <host>
>
> <external> --> <host> : works
> <host> --> <vserver> : works
> <vserver> --> <external> : works except for DNS resolution
> <external> --> <vserver> : does not work with any service.
>
> The DNS thing is kind of wierd... my resolv.conf is as follows:
>
> backup-server:/etc# cat resolv.conf
> nameserver 209.142.136.220
> nameserver 192.231.203.2
>
> I can ping the adress 209.142.136.220 from <vserver>. But still
> nothing will resolve Ex. "ping cnet.com". If I ping the ip address
> for cnet.com it will work though. I have another computer with a
> working vserver running fine so as a test I copied the entire vserver
> over and tried to run it on <host>, the problem was identical, so I
> believe the error to be with the setup of <host>.
>
> The following are the various dumps you requested,
> backup-server=<vserver>, backup=<host>,
> server=192.168.0.254=<external>. How do I check the tcp/udp protocols? *
>
> backup-server:/etc# netstat -l
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 backup-server:exec *:* LISTEN
> tcp 0 0 backup-server:login *:* LISTEN
> tcp 0 0 backup-server:shell *:* LISTEN
> tcp 0 0 backup-server:swat *:* LISTEN
> tcp 0 0 backup-server:time *:* LISTEN
> tcp 0 0 backup-server:discard *:* LISTEN
> tcp 0 0 backup-serv:netbios-ssn *:* LISTEN
> tcp 0 0 backup-server:daytime *:* LISTEN
> tcp 0 0 backup-server:pop3 *:* LISTEN
> tcp 0 0 backup-server:imap2 *:* LISTEN
> tcp 0 0 backup-server:www *:* LISTEN
> tcp 0 0 backup-server:ssh *:* LISTEN
> tcp 0 0 backup-server:smtp *:* LISTEN
> tcp 0 0 backup-server:imap3 *:* LISTEN
> udp 0 0 backup-serve:netbios-ns *:*
> udp 0 0 backup-serve:netbios-ns *:*
> udp 0 0 backup-server:discard *:*
> udp 0 0 backup-serv:netbios-dgm *:*
> udp 0 0 backup-serv:netbios-dgm *:*
> Active UNIX domain sockets (only servers)
> Proto RefCnt Flags Type State I-Node Path
>
> backup-server:/etc# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:4F:4E:03:D5:00
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:6837332 errors:0 dropped:10 overruns:0 frame:0
> TX packets:1366192 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:959297651 (914.8 MiB) TX bytes:430664716 (410.7 MiB)
> Interrupt:11 Base address:0xa000
>
> eth0:back Link encap:Ethernet HWaddr 00:4F:4E:03:D5:00
> inet addr:192.168.0.58 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Interrupt:11 Base address:0xa000
>
> lo Link encap:Local Loopback
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:8758 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8758 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:971104 (948.3 KiB) TX bytes:971104 (948.3 KiB)
>
> backup:~# cat /etc/vservers/backup-server.conf
> # Select an unused context (this is optional)
> # The default is to allocate a free context on the fly
> # In general you don't need to force a context
> #S_CONTEXT=
> # Select the IP number assigned to the virtual server
> # This IP must be one IP of the server, either an interface
> # or an IP alias
> # A vserver may have more than one IP. Separate them with spaces.
> # do not forget double quotes.
> # Some examples:
> # IPROOT="1.2.3.4 2.3.4.5"
> # IPROOT="eth0:1.2.3.4 eth1:2.3.4.5"
> # If the device is not specified, IPROOTDEV is used
> IPROOT=192.168.0.58
> # The netmask and broadcast are computed by default from IPROOTDEV
> #IPROOTMASK=
> #IPROOTBCAST=
> # You can define on which device the IP alias will be done
> # The IP alias will be set when the server is started and unset
> # when the server is stopped
> IPROOTDEV=eth0
> # Uncomment the onboot line if you want to enable this
> # virtual server at boot time
> ONBOOT=yes
> # You can set a different host name for the vserver
> # If empty, the host name of the main server is used
> S_HOSTNAME=backup-server
> # You can set a different NIS domain for the vserver
> # If empty, the current on is kept
> # Set it to "none" to have no NIS domain set
> S_DOMAINNAME=
> # You can set the priority level (nice) of all process in the vserver
> # Even root won't be able to raise it
> S_NICE=
> # You can set various flags for the new security context
> # lock: Prevent the vserver from setting new security context
> # sched: Merge scheduler priority of all processes in the vserver
> # so that it acts a like a single one.
> # nproc: Limit the number of processes in the vserver according to ulimit
> # (instead of a per user limit, this becomes a per vserver limit)
> # private: No other process can join this security context. Even root
> # Do not forget the quotes around the flags
> S_FLAGS="lock nproc"
> # You can set various ulimit flags and they will be inherited by the
> # vserver. You enter here various command line argument of ulimit
> # ULIMIT="-H -u 200"
> # The example above, combined with the nproc S_FLAGS will limit the
> # vserver to a maximum of 200 processes
> ULIMIT="-H -u 1000"
> # You can set various capabilities. By default, the vserver are run
> # with a limited set, so you can let root run in a vserver and not
> # worry about it. He can't take over the machine. In some cases
> # you can to give a little more capabilities (such as CAP_NET_RAW)
> S_CAPS="CAP_NET_RAW"
> #S_CAPS=""
>
>
> *From <extrernal> I did "ping backup" and "telnet backup" resulting in
> the following:
> *
> backup:/usr/src/kernel-patches/i386/apply# tcpdump -i eth0 host
> 192.168.0.254
> tcpdump: listening on eth0
> 15:19:25.591456 arp who-has server tell 192.168.0.45
> 15:19:31.911776 arp who-has server tell 192.168.0.20
> 15:19:36.705378 arp who-has server tell 192.168.0.10
> 15:19:38.498146 arp who-has server tell 192.168.0.51
> 15:19:46.968306 arp who-has server tell 192.168.0.111
> 15:19:51.120212 arp who-has server tell 192.168.0.31
> 15:19:56.070096 server.41704 > backup.telnet: S
> 3158940292:3158940292(0) win 5840 <mss 1460,sackOK,timestamp 50741796
> 0,nop,wscale 0> (DF) [tos 0x10]
> 15:19:56.070379 arp who-has server tell backup
> 15:19:56.070763 arp reply server is-at 0:c0:d:1:56:f3
> 15:19:56.070797 backup.telnet > server.41704: S
> 3178000667:3178000667(0) ack 3158940293 win 5792 <mss
> 1460,sackOK,timestamp 17268378 50741796,nop,wscale 0> (DF)
> 15:19:56.071044 server.41704 > backup.telnet: . ack 1 win 5840
> <nop,nop,timestamp 50741796 17268378> (DF) [tos 0x10]
> 15:19:56.089933 backup.telnet > server.41704: P 1:13(12) ack 1 win
> 5792 <nop,nop,timestamp 17268380 50741796> (DF) [tos 0x10]
> 15:19:56.090074 server.41704 > backup.telnet: . ack 13 win 5840
> <nop,nop,timestamp 50741798 17268380> (DF) [tos 0x10]
> 15:19:56.114702 server.41704 > backup.telnet: P 1:28(27) ack 13 win
> 5840 <nop,nop,timestamp 50741800 17268380> (DF) [tos 0x10]
> 15:19:56.114809 backup.telnet > server.41704: . ack 28 win 5792
> <nop,nop,timestamp 17268382 50741800> (DF) [tos 0x10]
> 15:19:56.114963 backup.telnet > server.41704: P 13:52(39) ack 28 win
> 5792 <nop,nop,timestamp 17268382 50741800> (DF) [tos 0x10]
> 15:19:56.149541 server.41704 > backup.telnet: . ack 52 win 5840
> <nop,nop,timestamp 50741804 17268382> (DF) [tos 0x10]
> 15:19:56.149914 server.41704 > backup.telnet: P 28:114(86) ack 52 win
> 5840 <nop,nop,timestamp 50741804 17268382> (DF) [tos 0x10]
> 15:19:56.151626 backup.telnet > server.41704: P 52:55(3) ack 114 win
> 5792 <nop,nop,timestamp 17268386 50741804> (DF) [tos 0x10]
> 15:19:56.151739 server.41704 > backup.telnet: . ack 55 win 5840
> <nop,nop,timestamp 50741804 17268386> (DF) [tos 0x10]
> 15:19:56.151788 server.41704 > backup.telnet: P 114:117(3) ack 55 win
> 5840 <nop,nop,timestamp 50741804 17268386> (DF) [tos 0x10]
> 15:19:56.157974 backup.telnet > server.41704: P 55:58(3) ack 117 win
> 5792 <nop,nop,timestamp 17268387 50741804> (DF) [tos 0x10]
> 15:19:56.158153 server.41704 > backup.telnet: P 117:120(3) ack 58 win
> 5840 <nop,nop,timestamp 50741804 17268387> (DF) [tos 0x10]
> 15:19:56.158238 backup.telnet > server.41704: P 58:87(29) ack 120 win
> 5792 <nop,nop,timestamp 17268387 50741804> (DF) [tos 0x10]
> 15:19:56.189398 server.41704 > backup.telnet: . ack 87 win 5840
> <nop,nop,timestamp 50741808 17268387> (DF) [tos 0x10]
> 15:19:56.189530 backup.telnet > server.41704: P 87:101(14) ack 120 win
> 5792 <nop,nop,timestamp 17268390 50741808> (DF) [tos 0x10]
> 15:19:56.189659 server.41704 > backup.telnet: . ack 101 win 5840
> <nop,nop,timestamp 50741808 17268390> (DF) [tos 0x10]
> 15:19:58.902392 server.41704 > backup.telnet: P 120:121(1) ack 101 win
> 5840 <nop,nop,timestamp 50742079 17268390> (DF) [tos 0x10]
> 15:19:58.902793 backup.telnet > server.41704: P 101:102(1) ack 121 win
> 5792 urg 1 <nop,nop,timestamp 17268661 50742079> (DF) [tos 0x10]
> 15:19:58.902875 backup.telnet > server.41704: P 102:103(1) ack 121 win
> 5792 <nop,nop,timestamp 17268661 50742079> (DF) [tos 0x10]
> 15:19:58.902923 server.41704 > backup.telnet: . ack 102 win 5840
> <nop,nop,timestamp 50742079 17268661> (DF) [tos 0x10]
> 15:19:58.902962 server.41704 > backup.telnet: . ack 103 win 5840
> <nop,nop,timestamp 50742079 17268661> (DF) [tos 0x10]
> 15:19:58.904072 backup.telnet > server.41704: F 103:103(0) ack 121 win
> 5792 <nop,nop,timestamp 17268661 50742079> (DF) [tos 0x10]
> 15:19:58.904248 server.41704 > backup.telnet: F 121:121(0) ack 104 win
> 5840 <nop,nop,timestamp 50742079 17268661> (DF) [tos 0x10]
> 15:19:58.904322 backup.telnet > server.41704: . ack 122 win 5792
> <nop,nop,timestamp 17268661 50742079> (DF) [tos 0x10]
>
> *From <external> to <vserver> first with ping then with telnet
> resulted in the following on <host>*
> 15:25:14.364511 arp who-has server tell 192.168.0.30
> 15:25:15.862745 server.41712 > backup-server.telnet: S
> 3493652297:3493652297(0) win 5840 <mss 1460,sackOK,timestamp 50773772
> 0,nop,wscale 0> (DF) [tos 0x10]
> 15:25:18.854215 server.41712 > backup-server.telnet: S
> 3493652297:3493652297(0) win 5840 <mss 1460,sackOK,timestamp 50774072
> 0,nop,wscale 0> (DF) [tos 0x10]
> 15:25:24.854682 server.41712 > backup-server.telnet: S
> 3493652297:3493652297(0) win 5840 <mss 1460,sackOK,timestamp 50774672
> 0,nop,wscale 0> (DF) [tos 0x10]
>
> *In both cases ping did not seem to show up at all on tcpdump.
>
> Thanks for your help, if this still does not make any sense I will
> try building a new kernel and install the latest version of the
> vserver software.
>
> Brandon.
> *
> Paul Sladen wrote:
>
>>On Fri, 31 Jan 2003, Brandon Hoult wrote:
>>
>>
>>>1. Yes, and I can ping the nameserver addresses from inside the vserver
>>>with no problems.
>>>
>>>
>>
>>Am I right in thinking that things like:
>>
>> vserver$ dig example.com @nameserver.ip
>>
>>just don't resolve/return?
>>
>>
>>
>>>- ping to vserver also will not work from anywhere except vservers host
>>>
>>>
>>
>>My initial thinking was that either the machine wasn't listening on the
>>external interface for traffic destined to the vserver's IPs, or that
>>routing wasn't getting the packets there in the first place.
>>
>>However, connections going *out* from the box's vserver are working fine,
>>which means that packets must be coming back too.
>>
>>Can you give me a dump of your network/LAN setup (off list if you would
>>prefer) and see what happens when you run `tcpdump' from the host server and
>>watch packets coming in.
>>
>> alpha:~# tcpdump -i eth0 host beta
>>
>> user_at_beta:~$ ping vserver
>> user_at_beta:~$ telnet vserver 22
>>
>>What do you see in the packet dump--are the packets been seen by the host
>>box? `Beta' should be the machine that you can see from the vserver, but
>>that you can't see the other way around.
>>
>>Make sure you check the TCP/UDP protocols are working--the ICMP echo reply
>>("ping") packets are answered at a much lower level by the kernel IP stack,
>>regardless of the vserver stuff.
>>
>>Can you also do a dump of `ifconfig' and the various `/etc/vservers/*'
>>config files.
>>
>> -Paul
>>
>>
>