Thank Norberto and Dan Farrell!I think i had a misunderstand and made some mistakes.I hope I have correct it now.
/etc/conf.d/net in the server config_eth0=( "202.114.10.134 netmask 255.255.255.0 brd 202.114.10.255" ) routes_eth0=( "default gw 202.114.10.129" ) config_eth1=( "192.168.1.1 netmask 255.255.255.0 brd 192.168.1.255" ) /etc/conf.d/net in a PC config_eth0=( "192.168.1.35 netmask 255.255.255.0 brd 192.168.1.255" ) routes_eth0=( "default gw 192.168.1.1" ) 2007/5/15, Dan Farrell <[EMAIL PROTECTED]>:
Greetings all. Hope the weather in bejing is pleasant, Mr Wu. On Mon, 14 May 2007 11:58:34 -0300 (ART) "Norberto Bensa" <[EMAIL PROTECTED]> wrote: > On Mon, May 14, 2007 8:23 am, Chuanwen Wu wrote: > > Thank you!I think i have done what you meant. > > Here is the information: > > > > > > /etc/conf.d/net in the server > > config_eth0=( "202.114.10.134 netmask 255.255.255.0 brd > > 202.114.10.255" ) routes_eth0=( "default gw 202.114.10.129" ) > > OK > > > > config_eth1=( "192.168.1.63 netmask 255.255.255.0 brd > > 192.168.1.255" ) routes_eth1=( "default gw 192.168.1.1" ) > > You don't need a route here. More exactly, a route to the subnet 192.168.1.0/24 will automatically be created through eth1. A _gateway_ in this case is not necessary because eth1 lives on that subnet. > > > /etc/conf.d/net in one PC > > config_eth0=( "192.168.1.35 netmask 255.255.255.0 brd > > 192.168.1.255" ) routes_eth0=( "default gw 192.168.1.1" ) > > No. GW should be 192.168.1.63, which is the IP address of your > gateway. > HTH, > Norberto > First, the firewall configuration. Your first message said: > The eth0 here has the real ip,and the eth1 have a subnet > ip:192.168.1.21. But here you show that you set it to .63, as Norberto pointed out. I assume that was just a typographical error in the first email. Moving on, the default route for the firewall is probably to the outside world, and if you can ping google.com, it works. Second, the client configuration. The route for the subnet it's on (192.168.1/24) is automatically created, as before. The default route is the IP of the firewall/gateway it's behind, namely 192.168.1.63 as Norberto said. The machine that's forwarding packets to the internet for these hosts now provides the route to the outside world for these hosts. Third, you must tell your client PCs nameservers, so that they can resolve domain names. If you fail to do so, even though a ping of google.com, for example, fails, a ping of its ip address (64.233.167.99, in my case) will work.
All my PCs have the same /etc/resove.conf file with the server.And now the PC can't ping through 66.249.89.99(of course,the server can).
Fourth, you must check your firewall (that is, iptables) configuration to be sure your iptables all refer to the correct subnet. > iptables --table nat -A POSTROUTING -s 192.168.8.0/24 -j MASQUERADE that wasn't right -- obviously the subnet should be your own.
I have already corrected it to "iptables --table nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE" from the first time.
Since the firewall you're building knows all the information the hosts need to know (subnet information, routes, etc) you may wish to set up a rudimentary DHCP server on it, so that additional hosts can be added without configuration by the user. You may also wish to impliment a caching, recursive nameserver for enhanced efficiency. DNSMasq can do both.
Thanks for your advice!
-- [EMAIL PROTECTED] mailing list
When a PC ping 66.249.89.99,I got these information from the server: # tcpdump -n -i eth1 net 192.168.1.0/24 and port not 22 and not arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 10:01:08.214160 IP 192.168.1.35 > 66.249.89.99: ICMP echo request, id 35391, seq 599, length 64 10:01:09.214014 IP 192.168.1.35 > 66.249.89.99: ICMP echo request, id 35391, seq 600, length 64 10:01:10.213899 IP 192.168.1.35 > 66.249.89.99: ICMP echo request, id 35391, seq 601, length 64 10:01:11.213792 IP 192.168.1.35 > 66.249.89.99: ICMP echo request, id 35391, seq 602, length 64 10:01:12.213676 IP 192.168.1.35 > 66.249.89.99: ICMP echo request, id 35391, seq 603, length 64 5 packets captured 5 packets received by filter 0 packets dropped by kernel And # tcpdump -n -i eth0 net 202.114.10.134 and port not 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes Does it mean that eth1(the interface in my subnet) receive the request but don't post forward it? -- wcw -- [EMAIL PROTECTED] mailing list
