Author Topic: Comments/Questions  (Read 1817 times)

anog

  • Newbie
  • *
  • Posts: 6
    • View Profile
Comments/Questions
« on: March 01, 2014, 01:38:01 PM »
First, I really want to say this is an excellent book.  I've been running Mac's for 20 years (in my home), used Windows Home Server for several years, them Mac OS X Server for at least one year. 

Anyway, I have my server at home as a hobby more than real business. I'd like to use it as a web server and learning experience. I have 5 PCs, 4 Macs, iPads, iPhones, and server is great for storing files and managing everything.  I'd also like to say that Open Directory and DNS problems have caused the need for MANY clean reinstalls.

I have other Mavericks Books, one even from Apple, and they are bad. Very basic and ignoring many issues. Your book is FANTASTIC, but if anything, maybe slightly a bit too far in the Enterprise direction, but that is O.K.

Like another reader, I was a bit confused on the IP addressing, and I understand that even if you have several fixed IP addresses, you keep inside addresses different. I understand DCHP, and DNS inside, but how it connects to the big world is something sometimes glossed over.

I also was a bit confused by SSL certificates. You say buy a cheap one with your server name of server.domain.com, BUT what if I want a web server?  I have discovered that www.domain.com DOES NOT match server.domain.com.  I do want to run a for-fun web site, so I also purchased another SSL with "domain.com" which also works with www.domain.com, but NOT server.domain.com.  Maybe in the future, a more in-depth discussion of SSL certificates is in order, or if you could recommend a book?  Even server alone uses "intermediate" certificates and code-signing certificates, and this can get confusing. I really have no idea if they are working or installed correctly.

Anyway, great book, and I will be looking for the next one. These are SO needed.


Reid Bundonis

  • Administrator
  • Full Member
  • *****
  • Posts: 107
    • View Profile
Re: Comments/Questions
« Reply #1 on: March 02, 2014, 10:50:06 AM »
Thank you so much!  I am glad it is helping.  Here are some thoughts.  I hope this helps.

IP Addressing
So I think I can make this a little clearer.  IPv4 which is our current network addressing method, has 4,294,967,296 total addresses.  Now, in the beginning of the Internet, this seemed like an incredibly large number.  But today, with the growth of the Internet, web, and connected users and businesses, this number is remarkably small and running out of numbers. 

Now, to mitigate the consumption of these addresses, a number of private address ranges where defined.  These are 192.168.0.0 - 192.168.255.255 (65,536 addresses), 172.16.0.0 - 172.31.255.255 (1,048,578 addresses), and the 10.0.0.0 - 10.255.255.255 (16,777,216 addresses) network blocks.  The simple explanation of this would be to use your own devices.  Without the private address space, your 5 PCs, 4 Macs, iPads, iPhones, and a server would consume one public address per device (maybe more for devices with wired and wireless interfaces).  So you alone might consume 15 or more public addresses.  You can imaging what would happen when a couple companies with a fleet of 10,000 laptops starts consuming addresses.  That IPv4 number set gets used very very quickly.

The use of private addresses on your LAN allows for a much more efficient use of the public range.  You get at least one public address and then you can use NAT (network address translation) and PAT (port address translation) or port forwarding to translate public traffic to your internal devices.  Here is a simple illustration to show how this works.

You have a single public address.  Let’s say 17.0.2.2.  This is assigned to your router and you want to host FTP, Mail, and VPN from inside your network.  In the first case, you have one server and it is doing all three tasks.  That server is at the private address of 192.168.0.10.  This is a simple NAT or port forwarding task.  You look at FTP (port 22), Mail (port 25), and PPTP VPN (port 1725), and you forward those ports to 192.168.0.10.  On the outside, you can define names for each service.  For example, mail.yourdomain.com will be an A record and point to 17.0.2.2.  Then you create two alias records (ftp and vpn) and point them to mail.yourdomain.com.  Now those three names are point to the same public address and you use your port forwarding rules to allow only those ports to come inbound.  All other ports will be blocked by your router/firewall.

Now on the inside of the network, the LAN.  You have one server that is doing mail, vpn, and FTP.  You have devices that move from your LAN to the WAN (phones, iPads, laptops).  You don’t want to constantly be updating configuration for your mail client.  For example, when on the LAN you would enter 192.168.0.10 to get mail but once you left you would reset the IP to 17.0.2.2.  Ouch.  That is a lot of work.  This is were split horizon DNS comes into play and one of the reasons why running DNS on your LAN is so important.  By replicating DNS internally, you now have an A record for mail pointing to 192.168.0.10 and two alias records for FTP and VPN.  Now, when a LAN client requests one of these services, it simply goes to the machine without needing to route over the internet.

Next, this can be expanded to handle a larger organization.  Let’s say you are a small company and you have a block of 5 public addresses (172.0.2.1 through 172.0.2.5).  You have the same requirements but you are going to run three independent servers.  One box for mail, one box for FTP and a third for VPN.  Then are at addresses 192.168.0.10, 192.168.0.11, and 192.168.0.12 respectively.  Now you use the same split horizon DNS but instead you use NAT, directing a public address to a private address.  172.0.2.1 -> 192.168.0.10, 172.0.2.2 -> 192.168.0.11, 172.0.2.3 -> 192.168.0.12.

That might be more info that you want, but hopefully that is a clear way of detailing the IP stuff. 

SSL Certificates
I think I can help on clearing up the concept of the SSL certificate.  There are a number of different ones for sale but for simplicity, there are standard certificates (single fully qualified host name) and wildcard certificates (*.yourdomain.com). 

I greatly simplified the chapter of SSL certificates simply because in most of my deployments, there is need for only one certificate.  Plus, I will admit never buying a wildcard (usually for price but also based on the concern that OS X might not handle it well).  Now, it should be pointed out that:

• The host name of the server and the name of the SSL certificate do not need to match.
• The server can have more than one SSL certificate installed.
• SSL certificates can be used for individual services if wanted.

So let’s look at these.  The first decision is do you need a certificate?  I tend to say yes all the time but that is because customers tend to want to use something on the machine that is safer with a certification.  This can include mail, contacts, calendars, profile manager, OD, FTP, and WWW.  And as I wrote, I also try to predict the future.  If I suspect there will be a need in the future, I rather be ready for it.  With the constant new features with Apple profile manager, I feel that every customer will end up using it to some extend.  And security is always a key part of the deployment.

On to the name of the server and the name of the certificate.  If your server is going to just run a web site and the site name is www.someotherdomain.com but you have already named the server server.yourdomain.com, then that is fine.  Purchase a certificate for www.someotherdomain.com and use it for web services only.  This will not impact the rest of the server since you are using this to protect a single virtual host in the web service.

As for having more than one, this is also possible and easy.  Say you are going to host mail for mail.yourdomain.com and web for www.someotherdomain.com.  Buy two certs (wildcard would not work here are the domains differ) and set one up for mail and the other for use by web services.

So yes, I greatly simplified the section to focus on the expectation that the name of the server chosen at installation will be used universally throughout.  But this is commonly not true, especially with web sites.

Let me know if that helps out a bit.

anog

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Comments/Questions
« Reply #2 on: March 24, 2014, 01:17:59 PM »
Thank you.  As time went by, I have learned much more on both the IP issue and SSL certificates issue. It all makes much more sense now, like everything once it all works. :-)  What you explained above makes perfect sense, but finding that actually explained in the real world was difficult. 

The SSL certificate issue was also a learning experience. I guess the part that tripped me up was the way Apple implemented its Web Server.  When you turn on the Web Server, you get a default web page. I had always assumed that you just remove that default web page eventually and replace it with your own.  WRONG.  You add your www.domain.com page to the Web Server, and THEN a service appears that you can associate your SSL certificate to.  I guess with my inexperience, I never knew that one web server could host pages for many domains and its smart enough to figure all that out.

Before I added my www.server.com site, there wasn't a place to associate my www.domain.com certificate, but there was the default site at server.domain.com  That was causing the confusion in my mind, so I didn't know how a server.domain.com certificate could work for www.domain.com?  It couldn't. 

So I learned, for www.domain.com you need a domain.com certificate, which works for www.domain.com  You may also need a server.domain.com certificate if you want to access the profile manager page securely at server.domain.com/mydevices, for example.  Or I guess, you could always keep the self-signed one for server.domain.com