From: Brandon Hoult (BrandonHoult_at_netscape.net)
Date: Mon 03 Feb 2003 - 18:57:09 GMT
It looks like the problem was in the iptables for the firewall. I don't
remember doing anything with these perhaps one of the debian updates
changed the settings. Anyway I set the policy on all the chains to
accept and everything works fine now. Thanks for your help.
Brandon.
Brandon Hoult wrote:
> 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
>>>
>>>
>>
>