NAT works for me under Ubuntu 12.04, and I'll gladly share what I know. Interventions from experts with more knowledge and/or confidence would still be welcome.
It may be helpful to split the problem into two steps. First is getting NAT to work at all, and connecting a thin client to the outside by manual intervention. Second can be making the relevant setup start automatically. I have two ethernet cards. eth1 is wired to a router that connects to the big wide world; eth0 is wired to the in-house subnet of LTSP boxes, visiting iPhones, etc. I got my NAT instructions from this web page: http://www.revsys.com/writings/quicktips/nat.html These describe how to enable NAT on a generic server box that is connected to the internet; all computers on the same subnet (be they LTSP clients or whatever) can communicate with the whole internet once this is running. The instructions seem compatible with what you have already done, but they are not Ubuntu-specific, so they don't mention adjusting /etc/network/interfaces at all. I didn't do that, but that's because I have a custom firewall made of a boatload of "iptables" commands that runs whenever my server boots. The script for that does include a line like the one you quote, but also a couple of others from the web page cited above. Here's what they look like in my setup: # LAN ... accept all packets originating on LAN iptables -A FORWARD -j ACCEPT -i eth0 # WAN ... accept expected incoming packets from WAN iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED # NAT happens here: output goes through WAN card eth1 iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE Note that you can give the command "sudo iptables -nvL" on the server to see what rules it is currently following. Some machine-readable analogue of the lines above should appear. Likewise you can say "cat /proc/sys/net/ipv4/ip_forward" and hope to see "1" to confirm that your sysctl command had the desired effect. Once the server is set up like this, you can save the job of messing with DHCP for later and start trying to get your client to send packets through it. Don't get too ambitious with human-readable names at first. Just ask the client to "ping 8.8.8.8". If you get something back, celebrate! That's Google's public DNS -- always up, and definitely outside. If you can ping 8.8.8.8, you can edit the file /etc/resolv.conf on the client and replace its contents with the single line nameserver 8.8.8.8 Then the client should be able to "ping www.google.com" successfully, and run a web browser with working navigation. Now for the extra challenge of making this success permanent. On my LTSP server, the file /etc/resolv.conf contains just two non-comment lines: nameserver 192.168.0.5 search treetop On my LTSP clients, the file /etc/resolv.conf contains four non-comment lines. It's just like two identical copies of the file above. One way my LTSP clients might be learning about the name server is from the DHCP negotiation when they boot. On my LTSP server, the file /etc/ltsp/dhcpd.conf includes the following two stanzas (and more). Maybe one of them will provide a useful clue: host k { hardware ethernet 00:01:2E:2C:AF:3E; fixed-address 192.168.2.102; option domain-name-servers 192.168.0.5; option broadcast-address 192.168.2.255; option subnet-mask 255.255.255.0; option root-path "/opt/ltsp/i386"; filename "/ltsp/i386/pxelinux.0"; } # Range of addresses for LTSP clients subnet 192.168.2.0 netmask 255.255.255.0 { range 192.168.2.113 192.168.2.120; option domain-name "treetop"; option domain-name-servers 192.168.0.5; option broadcast-address 192.168.2.255; option routers 192.168.2.115; option subnet-mask 255.255.255.0; option root-path "/opt/ltsp/i386"; if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" { filename "/ltsp/i386/pxelinux.0"; } else { filename "/ltsp/i386/nbi.img"; } } Or maybe the magic is being achieved by the file on my LTSP server named /var/lib/tftpboot/ltsp/i386/lts.conf The [default] section includes some seemingly-relevant lines. I quote the whole section: [default] X_COLOR_DEPTH=24 LOCALDEV=True SOUND=True VOLUME=90 NBD_SWAP=True SCREEN_06=shell SCREEN_07=ldm LDM_SESSION="gnome-session --session=gnome-fallback" LOCAL_APPS=True LOCAL_APPS_EXTRAMOUNTS=/media SEARCH_DOMAIN=treetop DNS_SERVER=192.168.0.5 I hope there is something here you can use. Yours sympathetically, Philip On 08/15/2012 12:28 PM, John Hupp wrote: > As I understand it, the Local Apps settings are enabled by default in > Lubuntu 12.04. Once LTSP is also installed, that means that one can run > on the LTSP client hardware (instead of the LTSP server hardware) any > app that is installed in the LTSP chroot image. For instance, xterm can > be run on the client via "ltsp-localapps xterm" (ltsp-localapps being > the script command by which an app must be launched locally). > > To run an additional app locally, just install it in the chroot and > update the image: > sudo chroot /opt/ltsp/i386 > sudo apt-get install <app-of-your-choice> > sudo ltsp-update-image > > HOWEVER, Internet apps will launch but not work at this point due to > Name Resolution failure. So the LTSP server has to be set up as a NAT > gateway. > > As far as I know, the most relevant instruction for doing that is here: > https://help.ubuntu.com/community/UbuntuLTSP/ThinClientHowtoNAT/ > > But I have not gotten that working, so I want to summarize the steps of > that instruction here and insert comments about my own implementation. I > trust someone will spot the problem. > > ** Edit /etc/ltsp/dhcpd.conf (sudo gedit /etc/ltsp/dhcpd.conf) setting > the routers option to the ip address of the ltsp server on the ltsp > network. eg > option routers 192.168.0.254; > and restart the dhcp server > sudo /etc/init.d/dhcp3-server restart > ON 11.10 restart the dhcp server > sudo /etc/init.d/ish-dhcp-server restart > Test: Reboot the test PC on the thin client network and check if it sees > the new default gateway (on linux type ip route and look at the line > beginning "default"; on windows type "route print" into a command prompt > and look for default gateway). > > [COMMENT: I understand that LTSP servers have variously been set up with > default 192.168.0.254 or 192.168.0.1, but that now people are pressing > for a uniform default of 192.168.0.1, which is the way mine is set up. I > found dhcpd.conf already had "option routers 192.168.0.1" enabled. And > my test PC did indeed show a default gateway of 192.168.0.1.] > > ** On the LTSP server edit /etc/sysctl.conf (sudo gedit > /etc/sysctl.conf) and either add this line or uncomment if it's already > there: > net.ipv4.ip_forward=1 > which will take effect at next server reboot. To make the setting > effective immediately, now run the command > sudo sysctl -w net.ipv4.ip_forward=1 > > [COMMENT: I only had to un-comment the line.] > > ** Enable network address translation. By default the ltsp network > address/mask is 192.168.0.0/24. Remember to change the example to fit > your network setup. Use a command like: > sudo iptables --table nat --append POSTROUTING --jump MASQUERADE > --source 192.168.0.0/24 > to enable NAT. To make this setting permanent run > sudo sh -c 'iptables-save > /etc/ltsp/nat' > and add the extra line up iptables-restore < /etc/ltsp/nat to the bottom > of the eth0 (or whichever is your LTSP interface) stanza of > /etc/network/interfaces so it looks something like > auto eth0 > iface eth0 inet static > address 192.168.0.254 > netmask 255.255.255.0 > broadcast 192.168.0.255 > network 192.168.0.0 > up iptables-restore < /etc/ltsp/nat > This creates a script called /etc/ltsp/nat which restores the NAT next > time the eth0 network interface comes up. Test: ping the dns server on > the main network from the test PC. > > [COMMENT: I used the first two commands as written. My network is the > default 192.168.0.0/24. And since my LTSP interface it eth1, I added > the following to interfaces: > auto eth1 > iface eth1 inet static > address 192.168.0.1 > netmask 255.255.255.0 > broadcast 192.168.0.255 > network 192.168.0.0 > up iptables-restore < /etc/ltsp/nat > But I thought it of interest that neither eth0 nor eth1 was initially > configured via /etc/network/interfaces. Lubuntu seems to prefer > Preferences: Network Connections, a nice GUI, and that is what I used to > set up eth1 for LTSP. But here, I didn't know how to use Network > Connections to add "up iptables-restore < /etc/ltsp/nat." So I hoped > editing interfaces as instructed would do the job.] > > ** Again, edit /etc/ltsp/dhcpd.conf, as above, setting the dns option to > the ip address of the main network DNS server (listed in > /etc/resolv.conf on the LTSP server beside the word "nameserver"), e.g. > option domain-name-servers 192.168.1.1; > and again restart the dhcp server > sudo /etc/init.d/dhcp3-server restart > Test: Reboot the test PC again, to update its DNS server. Try pinging a > real world server from the test PC by name, eg > ping www.ubuntu.com > > [COMMENT: /etc/resolv.conf showed 127.0.0.1 for the nameserver. Given > the instruction's example of 192.168.1.1, this address seems unexpected, > but I tried it and it did not work. I also tried 192.168.0.1. Also > 192.168.1.1, the address of the router, which I would have taken to be a > good bet. I also set the router to 10.0.0.1/255.255.255.0 and tried > that for the dhcpd.conf domain-name-server. (See more on that below.) > Finally I tried the openDNS servers that are set up in the router: > 208.67.222.222; 208.67.220.220. Most of my failures simply resulted in > Name Resolution failures when local app chromium-browser was trying to > find a site. But at this point, something in my configuration seems to > have disabled LTSP DHCP altogether -- the LTSP client does not boot.] > > ----------------------------------- > > MORE GENERAL INFO: My DSL modem is an AT&T that uses a non-configurable > LAN-side address of 192.168.0.1/255.255.0.0. > > Initially I had the router set to 10.0.0.1/255.255.255.0, and computers > on the main network can ping and open the configuration page for the > modem. I was concerned that this would conflict with the LTSP server at > 192.168.0.1, but LTSP clients worked OK -- perhaps because of the > differing netmasks of 255.255.255.0 vs. 255.255.0.0?? > > I also tested setting the router at 192.168.1.1/255.255.0.0. In this > configuration computers on the main network cannot see the modem at > 192.168.0.1. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
