| rdfs:comment
| - Occasionally, I've been in a situation where bridged network is too instrusive (No IP addresses available, I don't have access to change the host's IP setup, etc), and ICS (Internet Connection Sharing) disrupts the point of your coLinux setup (In otherwords, you don't want to Port Forward everything from the host to the guest OS, or you want the Guest and the Host to keep seperate identities while on the network). Anyways, to setup up such a network to work as above, the following assumptions are made: Thats about it. If you have any questions, you can reach me at ibonny at gmail dot org. Ian
|
| abstract
| - Occasionally, I've been in a situation where bridged network is too instrusive (No IP addresses available, I don't have access to change the host's IP setup, etc), and ICS (Internet Connection Sharing) disrupts the point of your coLinux setup (In otherwords, you don't want to Port Forward everything from the host to the guest OS, or you want the Guest and the Host to keep seperate identities while on the network). For those in a similar situation, there is another way to properly put your coLinux machine on the Internet, and it doesn't involve a lot (read: one) of changes to the host system. This document is geared towards the co Linux on Windows setup, only because I haven't successfully gotten coLinux working on Linux, and this type of setup is pretty moot on a Linux machine (its even simpler to do there). Anyways, to setup up such a network to work as above, the following assumptions are made: 1.
* Your host machine is sitting on a network of 192.168.x.0/24 (In otherwords, any class C network on the 192.168 class B network) 2.
* Your guest machine is sitting on a network of 192.168.y.0/24 (In otherwords, any class C network on the 192.168 class B network thats NOT the same as the host system's network.) IT IS IMPERATIVE THAT THE NETWORKS OF GUEST AND HOST SYSTEMS ARE DIFFERENT. Sorry about the yelling, but this setup will not work unless the previous is true. 3.
* You have access to change the registry of your host system. (This is the one change I mentioned above) 4.
* Your router that you use to reach the Internet (which I'm assuming supports NAT, but doesn't necessarily have to) can do static routes. If you can't change your router, then you're probably stuck using ICS for your system. To set up the system to properly work, first, add a network route on your router to direct all traffic for 192.168.y.0/24 to the IP address of your HOST system (So, if your host system is sitting on 192.168.x.3, then enter a route that reads: 192.168.y.0/24 is routed through 192.168.x.3). Secondly, make sure that your guest machine's IP address is pointed at 192.168.y.1. (this should be the address of your Host machine's TAP device. If its not, change it so that it is). Technically, any address for the TAP address can be used, but using .1 makes things a lot simpler. Lastly, start tracerouting and pinging towards the Internet. If everything above was set up correctly, your coLinux system should now be able to reach the Internet. You should see hops from traceroute of: 192.168.y.1 192.168.x.1 (or whatever your router's IP address is) - the internet - (whatever IPs they are publically) This way, you should be able to talk between the host and the guest machines via the 192.168.y.0/24 network (if your guest is 192.168.y.5 and your host is 192.168.y.1, then its quite simple). I would lastly suggest that you place a DNS server in your coLinux guest machine to simplify communication between coLinux and its DNS server. Thats about it. If you have any questions, you can reach me at ibonny at gmail dot org. Ian The above did not work for me. Just because packets are going from the guest to the host, does *not* mean the host will forward them. Similarly, just because your router is bringing packets back for your 192.168.y.0/24 network to your host machine, that does not mean it will forward them to your guest machine's tap interface. I think the author of the above left out one step; he did mention something about a "registry change" but never actually talked about one. There is a way to enable packet forwarding in Windows; from a knowledge base article: To enable TCP/IP forwarding, follow these steps: 1.
* Start Registry Editor (Regedit.exe). 2.
* In Registry Editor, locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 3.
* Set the following registry value: 4.
* Value Name: IPEnableRouter 5.
* Value type: REG_DWORD 6.
* Value Data: 1 7.
* A value of 1 enables TCP/IP forwarding for all network connections that are installed and used by this computer. 8.
* Quit Registry Editor. I found a reboot was required after this to kick it into action. -dale The above is a very helpful approach in the case where you have a Windows ICS internet gateway machine in your office/house/whatever, which forces your internal LAN to be 192.168.0.* and thus eliminates the possibility of using ICS on your host machine, *and* you're using a wireless card on the host machine, which can prevent Windows native bridging from working properly on the host. I did something slightly different, to solve this problem; used the free Proxy Plus program, to proxy all requests from the guest OS through the host OS. Not as elegant and thorough as the approach suggested here, but if you don't have access to change static routes, and have the other restrictions I mention, it is a viable alternative. (I also tried using WinGate on the host machine, but since the TAP interface didn't exist in a state it liked at boot time, WinGate's drivers refused to consider it for use.) -Dale Another trick is to do "proxy arp routing". So in addition to turning on IP forwarding (as suggested above) and installing a route to the IP address assigned to coLinux, the last step is to add a static arp entry so that windows will respond to arp requests that are intended for co Linux. For example, suppose your Windows ethernet mac address is 00:aa:11:22:33:44, windows IP address is 128.95.2.4, and the coLinux IP address is 128.95.2.16, then you'd do the following from a command prompt on Windows: c:> arp -s 128.95.2.16 00-aa-11-22-33-44 128.95.2.4 Then a host route command on Windows such that packets destined to 128.95.2.16 are routed properly. -Marc MassTranslated on Sun Apr 23 17:37:07 UTC 2006
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)