”Dual-booting with Windows and desktop Linux is a snap to do.”
This statement is at best a half-truth as it really depends on the skill set of the person trying to install Linux along side Windows.
Despite this, I hear people stating this as a fact nearly everyday. Drives me bananas.
When it comes to running multiple operating systems on a computer, I think that most distro providers do little to deter their users from making what can be serious partitioning mistakes.
Figuring that it must be the end user's sole responsibility to "get it right," people are often seen in the various users forums complaining how Linux deleted their Windows install. Clearly there has to be a more consistent way of addressing this.
One near foolproof approach is to run with a dedicated Linux PC. Not a practical solution for everyone, but a solid option nonetheless.
The second approach might be to make a disk image of your Windows installation. This way if the dual-booting setup goes wrong and repairing the MBR doesn't help due to the partitioning being done improperly, the end user is not totally out of luck trying to recover their Windows files.
Even with backups, the end user often finds themselves in a position where they do not understand how to avoid partitioning and MBR issues in the first place.
In this article, I’ll addressing this and hopefully provide the typical end user with some duplicable solutions.
Thinking Ubuntu? Think Wubi
For individuals already thinking of taking Ubuntu for a spin, I've found myself pointing to Wubi – a Ubuntu installer for Windows users – with increasing frequency. The reasons are fairly obvious.
Like a Live CD, no changes are made to your partitioning scheme. This means no data loss. Second, you will find that you’re able to use your existing MBR provided by Windows, rather than overwriting anything.
And lastly, all of the Ubuntu files are installed into a folder on your Windows installation. This means not only are you able to remove Wubi from Add/Remove programs in Windows, installation is also done as a simple EXE file.
For existing Windows users looking to move beyond a LiveCD, Wubi provides a very solid option.
Acronis Disk Director Suite
Not normally being a huge fan of Windows software, I do have a different view of Acronis Disk Director Suite.
For those individuals that simply must dual-boot Windows and Linux, this is my recommended approach.
Even though it is not deemed as necessary since it is possible to dual-boot without it, inexperienced users will find this is vastly safer to use than rolling the dice and hoping you remember which partition is which when installing that second OS.
The features that I like the best about Acronis Disk Director include Partition Recovery and the Boot Manager.
As many Vista users have discovered, Windows Vista does not always play well with Ubuntu installed afterward.
Not the fault of the latter installation, rather Vista refusing to cooperate. Acronis Disk Director Suite's boot manager can help with this.
Going Virtual with a virtual machine
With very few exceptions for gaming and other intensive software, modern PCs actually do very well running Windows guest OS installs on Linux hosts.
I prefer using VirtualBox while others will possibly lean toward VMWare.
In either case, you have working USB options and are able to install practically any Windows software needed.
People that prefer Windows over Linux are free to do the same thing described above, but in reverse. Both instances negate the need to dual-boot their computers for most people.
Think about this: if you are merely looking to access Internet Explorer 8 or sync your iPhone via USB with iTunes, do you really believe that this requires a dual-boot system? Hardly.
For most people, using a virtualized solution is more than enough regardless of which OS is being called into question.
The key is whether or not legacy software is in use that would simply over-tax available resources. Short of this, I see no reason not to take this approach.
Throwing caution to the wind
Regardless of everything I have said above, there are going to be individuals who swear that dual-booting is perfectly easy.
It is my opinion that they are demonstrating great arrogance with this mindset, but let's explore this argument regardless.
Assuming the individual user looking to dual-boot their two operating systems found a tutorial that was in fact accurate, then there is the matter of ensuring that they fully realize which partition is which.
Why? Because many tutorials have users working with partitioning tools that give no clear indication as to which partition now contains the Windows installation.
It’s be up to the end user to remember the size of each partition to make sure mistakes are avoided.
Can most new users actually do this? Should they be expected to install two different operating systems side by side? This is fine and well for advanced users like us, but it’s a fast track to a mishap for most people.
Common sense revisited
I'm certainly not advocating dumbing down the Linux experience. No, instead I would like to make sure people fully understand what they are doing before jumping into dual-booting their computers blind.
Comprehending all of the risks involved is key when trying to establish a dual-boot setup.
So while many advanced users will continue to scoff at this notion as utter nonsense, not everyone out there has had to deal with a lack of understanding in working with multiple operating systems on the same computer.
What I would love for everyone to take away from this article is first, remember that not everyone is fluent in using computers.
So to assume that providing a random link to dual-booting is all that is needed for someone to make it happen, is naive at best...irresponsible at worst.
I believe that along with a full disclosure of what it means to start messing with existing partitions, one might also mention that most people would do well to avoid dual-booting altogether.
This may seem a bit absolute to some, but I can promise you that adding an Ubuntu guest installation to a VM in Windows does a lot less harm that trying to manipulate random partitions blindly.
Saturday, October 31, 2009
Build an IPSEC VPN Without Losing Your Mind
With latency-sensitive or high bandwidth requirements, often we find OpenVPN unable to perform. IPSEC is the solution, but the barrier to using IPSEC is great.
It is potentially difficult to configure, and one's first exposure to VPN concepts is often confusing.
With the concepts explained, the task of actually making IPSEC work becomes much more tenable.
Likewise, using Openswan, the fork and improvement of FreeS/WAN, makes configuring IPSEC almost fun.
We will explain how to create a network-to-network connection so hosts at two remote sites can communicate with each other.
If you have trouble setting this up, first try host-to-host mode, using the excellent tutorial on the Openswan wiki.
Concepts
To successfully run Openswan, there are only four things you need:
Openswan also takes care of adding routing table entries, so this list is really all you need for the basic "make one subnet reach another" configuration.
After configuring a tunnel, Openswan will inherently know which traffic is destined for the network on the other side of the tunnel, and automatically adds the route.
Of course, you can send traffic for more subnets through the IPSEC tunnel, assuming the gateway on the other end knows how to route there.
When everything else is working, simply add another route similar to the one Openswan adds for you, but for the other network.
When configuring IPSEC, you need to draw out your subnets and which interfaces are on the gateways, and label them accordingly.
Using the intuitive left/right terminology from Openswan (because all diagrams of this nature are two-dimensional, and in/out or local/remote mean different things to different people), create a diagram similar to the figure below with your own information:
If a key was generated by your installer package, you can retrieve it by running
# ipsec showhostkey --left
We will use the resulting key for the configuration file. If instead you see something like "ipsec showhostkey: no default key in /etc/ipsec.secrets," you will need to generate one as root: ipsec newhostkey --output /etc/ipsec.secrets
Repeat the process on the other side of the soon-to-be VPN, and you should now have two keys.
The ipsec.conf file is really quite simple with Openswan. We are now going to combine all the information previously gathered above.
# Openswan ipsec.conf
conn GatewayA-to-GatewayB
left=4.3.2.1
leftsubnet=10.1.0.0/24
leftid=@a.example.com
leftrsasigkey=0sAQNe...
leftnexthop=%defaultroute
right=1.2.3.4
rightsubnet=10.2.0.0/24
rightid=@b.example.com
rightrsasigkey=7xoprFh...
rightnexthop=%defaultroute
auto=start
The "left" and "right" declarations are externally accessible IP addresses of the gateway routers. The "leftid" is the hostname of the machine.
Copy this file to Gateway B, and you are ready to start the tunnel on both ends:
# ipsec auto --up GatewayA-to-GatewayB
The quick test is of course to ping the external IP of Gateway B from Gateway A. You will notice a route in the routing table that directs this traffic, and traffic to the defined rightsubnet through the tunnel.
If IP forwarding is enabled, as it probably is, given that these machines are both already routers, you can now try pinging a host in the remote subnet.
That certainly wasn't hard. You can also define more connections in the same configuration file. They are differentiated by the leftid and rightid parameters, allowing you to use a single configuration across many hosts.
Filter rules designed to detect TCP/UDP ports, or even specific upper layer protocols, will not be able to see that data until the packet is decrypted.
You can mark packets, or use policy match rules; both are convoluted, but have been discussed at length on various mailing lists including the Openswan list.
One other reason for IPSEC failing to start could be blocked ports. First get it working without iptables in the way, to make sure IPSEC is configured and working, then re-enable the firewall. Port 500 needs to be reachable by both IPSEC endpoints, for IKE, the key exchange protocol.
We can't stress enough that configuring IPSEC is actually quite painless--until you add NAT or firewalls into the picture.
You absolutely must test the IPSEC connection outside of any firewall or NAT presence to ensure it is working, before adding back the challenging piece (if you absolutely must). Your sanity will be preserved, and the installation process time dramatically reduced.
It is potentially difficult to configure, and one's first exposure to VPN concepts is often confusing.
With the concepts explained, the task of actually making IPSEC work becomes much more tenable.
Likewise, using Openswan, the fork and improvement of FreeS/WAN, makes configuring IPSEC almost fun.
We will explain how to create a network-to-network connection so hosts at two remote sites can communicate with each other.
If you have trouble setting this up, first try host-to-host mode, using the excellent tutorial on the Openswan wiki.
Concepts
To successfully run Openswan, there are only four things you need:
- a pre-shared key to make encryption work
- to know the IP addresses of the two gateway servers on each end
- to know the subnet ranges of the networks at each end
- a drawing, if this is your first time
Openswan also takes care of adding routing table entries, so this list is really all you need for the basic "make one subnet reach another" configuration.
After configuring a tunnel, Openswan will inherently know which traffic is destined for the network on the other side of the tunnel, and automatically adds the route.
Of course, you can send traffic for more subnets through the IPSEC tunnel, assuming the gateway on the other end knows how to route there.
When everything else is working, simply add another route similar to the one Openswan adds for you, but for the other network.
When configuring IPSEC, you need to draw out your subnets and which interfaces are on the gateways, and label them accordingly.
Using the intuitive left/right terminology from Openswan (because all diagrams of this nature are two-dimensional, and in/out or local/remote mean different things to different people), create a diagram similar to the figure below with your own information:
If a key was generated by your installer package, you can retrieve it by running
# ipsec showhostkey --left
We will use the resulting key for the configuration file. If instead you see something like "ipsec showhostkey: no default key in /etc/ipsec.secrets," you will need to generate one as root: ipsec newhostkey --output /etc/ipsec.secrets
Repeat the process on the other side of the soon-to-be VPN, and you should now have two keys.
The ipsec.conf file is really quite simple with Openswan. We are now going to combine all the information previously gathered above.
# Openswan ipsec.conf
conn GatewayA-to-GatewayB
left=4.3.2.1
leftsubnet=10.1.0.0/24
leftid=@a.example.com
leftrsasigkey=0sAQNe...
leftnexthop=%defaultroute
right=1.2.3.4
rightsubnet=10.2.0.0/24
rightid=@b.example.com
rightrsasigkey=7xoprFh...
rightnexthop=%defaultroute
auto=start
The "left" and "right" declarations are externally accessible IP addresses of the gateway routers. The "leftid" is the hostname of the machine.
Copy this file to Gateway B, and you are ready to start the tunnel on both ends:
# ipsec auto --up GatewayA-to-GatewayB
The quick test is of course to ping the external IP of Gateway B from Gateway A. You will notice a route in the routing table that directs this traffic, and traffic to the defined rightsubnet through the tunnel.
If IP forwarding is enabled, as it probably is, given that these machines are both already routers, you can now try pinging a host in the remote subnet.
That certainly wasn't hard. You can also define more connections in the same configuration file. They are differentiated by the leftid and rightid parameters, allowing you to use a single configuration across many hosts.
Why This Is Difficult
First of all, if you are using iptables to filter or NAT packets, the above test may not have been successful.
The quick and easy way around NAT is to modify your MASQUERADE rule, on both ends, to exclude the internal destination on the opposite.
Traffic destined for the subnet behind the other NAT cannot be NAT'd, as NAT attempts to modify layer 4 headers, which are encrypted.
Everything in the IP data section, including TCP and UDP packets in their entirety, are encrypted and cannot be changed.
Furthermore, if you are attempting to start an IPSEC connection from a box that lives behind (a possibly secret) NAT device, it will fail. The NAT device can be configured to allow IPSEC passthrough for you, though.
Filtering traffic with IPSEC in the mix gets messy. When the packet arrives, everything but the first part of the IP header is encrypted.Filter rules designed to detect TCP/UDP ports, or even specific upper layer protocols, will not be able to see that data until the packet is decrypted.
You can mark packets, or use policy match rules; both are convoluted, but have been discussed at length on various mailing lists including the Openswan list.
One other reason for IPSEC failing to start could be blocked ports. First get it working without iptables in the way, to make sure IPSEC is configured and working, then re-enable the firewall. Port 500 needs to be reachable by both IPSEC endpoints, for IKE, the key exchange protocol.
We can't stress enough that configuring IPSEC is actually quite painless--until you add NAT or firewalls into the picture.
You absolutely must test the IPSEC connection outside of any firewall or NAT presence to ensure it is working, before adding back the challenging piece (if you absolutely must). Your sanity will be preserved, and the installation process time dramatically reduced.
VSFTPD Chroot Jail for FTP
Chroot Jail for FTP Users
One concern when users FTP into your server, is that by default users who have accounts can roam your server to view contents of files.
VSFTPD by default does not allow user logins, it allows anonymous by default. Anonymous users by default are locked into the directory that they login to.
This is exactly what you would want. However, if you set up user FTP accounts you will probably want to limit those users so they can only access their own files and not other users. In order to achieve this you must place them in a chroot jail.
Jail All Users
In order to jail all users, keep them in their home directories, use these settings in the /etc/vsftpd.conf.
chroot_local_user=YES
Add these settings to allow anonymous logins using regular FTP and allow users to login using SSL.
anonymous_enable=YES
local_enable=YES
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
This creates a very useful and secure set up.
Allow Some Users to Roam the Server
You also have the option to allow special users to login and be able to move around the server. This means that these will not be jailed.
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
Now edit the /etc/vsftpd.chroot_list file and enter the users you want to allow to roam the server in this file. Enter one user at a time in this list.
Add these settings to allow anonymous logins using regular FTP and allow users to login using SSL.
anonymous_enable=YES
local_enable=YES
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
One concern when users FTP into your server, is that by default users who have accounts can roam your server to view contents of files.
VSFTPD by default does not allow user logins, it allows anonymous by default. Anonymous users by default are locked into the directory that they login to.
This is exactly what you would want. However, if you set up user FTP accounts you will probably want to limit those users so they can only access their own files and not other users. In order to achieve this you must place them in a chroot jail.
Jail All Users
In order to jail all users, keep them in their home directories, use these settings in the /etc/vsftpd.conf.
chroot_local_user=YES
Add these settings to allow anonymous logins using regular FTP and allow users to login using SSL.
anonymous_enable=YES
local_enable=YES
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
This creates a very useful and secure set up.
Allow Some Users to Roam the Server
You also have the option to allow special users to login and be able to move around the server. This means that these will not be jailed.
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
Now edit the /etc/vsftpd.chroot_list file and enter the users you want to allow to roam the server in this file. Enter one user at a time in this list.
Add these settings to allow anonymous logins using regular FTP and allow users to login using SSL.
anonymous_enable=YES
local_enable=YES
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
ssl_enable=YES
force_local_logins_ssl=YES
force_local_data_ssl=YES
Subscribe to:
Posts (Atom)
