My server is connected to the internet through one interface, and to the
in-house subnet where LTSP clients live through a second interface. So I
had to run through steps like the ones you quote *on my server*; my
reference for this was
http://www.revsys.com/writings/quicktips/nat.html
But if you have some (thin) clients that see the internet and some (fat)
others that don't, then it's likely that your server settings are fine
and it's your fat clients that need tweaking. You could try opening a
terminal from a running fat client and using the command
ltsp-localapps xterm &
to open a session that addresses the fat-client system directly. In the
terminal window that opens, entering the command
/sbin/route
will show you how the fat-client proposes to address the internet. On my
working system, the transcript is this (with better line breaks):
==================================
phi...@ltsp101 ~ $ /sbin/route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
default server 0.0.0.0 UG 0 0 0 eth0
==================================
The second line ("default ...") here is key: it confirms that the LTSP
server is being used as the NAT-transfer point connecting the client to
the world beyond.
How does the client know what gateway to use? It gets told by the DHCP
server running on the server box; perhaps the server's "lts.conf" file
offers another way to communicate this information, too. That's a
natural target for scrutiny because it's most likely the place where you
have different initializations for your two species of clients.
To test the client's outbound connection, say "ping 8.8.8.8" in the
xterm window described above. You'll get packets back from google if and
only if the NAT setup is operational.
Hope this helps. Good luck! - Philip
On 11-01-06 06:20 PM, Peter Scheie wrote:
> I've using the stock LTSP install from Ubuntu 10.4 and it's working swimmingly
> for the thin clients. My notes from a few years ago on enabling non-thin
> client
> machines to plug into the same switch as the thin clients and be able to get
> out
> to the internet were as follows:
>
> * echo 1>/proc/sys/net/ipv4/ip_forward
> * edit /etc/sysctl.conf to make that permanent
> * iptables -t nat -A POSTROUTING -j MASQUERADE
> * iptables-save
> * install& start dnsmasq
>
> The DNS part is working--the fat client can resolve names to addresses--but
> the
> forwarding isn't working. I've double-checked /proc/sys/net/ipv4/ip_forward
> and
> it's now set to 1 (true). But when the client tries to connect to an address
> on
> the internet, it fails. Any suggestions as to how to debug this? Thanks.
>
> Peter
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_____________________________________________________________________
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
