Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

System Admin is not my strong point. My situation is we have 1 website that has 4 domains. The website itself serves different templates/content depending on which domain is used, simulating 4 different websites.

We want SSL for each domain (we currently have it all set up properly with apache and it is working on 3 sites).

We have 3 physical network interfaces: eth5, eth6, eth7. A past employee wrote these ip route rules to help setup our virtual host IP addresses. I don't really understand what's going on on these, except that with these in place, 3 of our domains work properly with SSL, corresponding to virtual hosts for each ip address *.95

Eth5
ip route add *.*.*.0/24 dev eth5 proto kernel scope link src *.*.*.95 table 20
ip route add default via *.*.*.1 dev eth5 table 20
ip rule add from *.*.*.95 lookup 20 

Eth6
ip route add *.*.*.0/24 dev eth6 proto kernel scope link src *.*.*.12 table 40
ip route add default via *.*.*.1 dev eth6 table 40
ip rule add from *.*.*.12 lookup 40

Eth7
ip route add *.*.*.0/24 dev eth7 proto kernel scope link src *.*.*.11 table 30
ip route add default via *.*.*.1 dev eth7 table 30
ip rule add from *.*.*.11 lookup 30

These rules have worked for 3 of the 4 websites we need SSL. We have another IP address *.14 that we have told our internal (bind9) and godaddy DNS (correlating to the public IP for *.14 which is *.70) to point here. But I feel like I need to be adding another rule.

I want to know what these rules do, why I need a rule, and how I can make .14 actually work.

The domain that I want to point to 14 is pointing to 12 (on our internal site). Externally it is pointing to 70 which is 14 so nothing is showing up, because that part is not working!


Edit to Answer Florenz's comment:

Our server is running Ubuntu 12.10. We have apache that handles our virtual hosts with a folder called sites-available and another sites-enabled. I have that part all working properly, where there are four sites available and enabled, containing virtual hosts.

In those, we have <virtualhost> that contain the IP addresses that correpsond to .95, .11, .12 and the one not working .14 Since they use SSL, they use the Port:443

All the SSL certs are running and linked in there as well. I don't think that the apache side of the virtual hosts are not done correctly. I think it has to do with these IP Route rules. I don't really know much about this stuff so it's hard to explain it.

share|improve this question
    
your description confuses me a bit. Could you please try to describe in more detail what you have in "layers" of stuff, and with the corresponding config file entries? What type of deployment? OS? Webserver? server instances? other dependencies? Have a look at httpd.apache.org/docs/2.4/vhosts/ip-based.html for the Apache docs on IP-based virtual hosts (the glimpse of your config suggests something in that direction) –  Florenz Kley Aug 14 '13 at 19:26
    
Edited my question. Hopefully that helps? What do you mean by layers? –  amurrell Aug 14 '13 at 22:22
    
layers = what components need to be there to make it work. Usually diagrammed as layers. I'm tempted to say re-hire the guy :-). Have a look at your ifconfig - where does the new IP end? Depending on the way it comes in (VLAN?) you may be ablw to test with a virtual interface, not a physical one. Have a look at ip, netstat and route, that shows you the route setup (this is where the route command comes in). Check iptables (if you use the firewall). Check QOS/throttling (tc et al). –  Florenz Kley Aug 14 '13 at 23:48
    
Hiring him back is not an option or a desire. I mentioned this is not my field. I need a step by step. Perhaps you could provide references for how to setup a virtual interface. And how to look at the iptables, because that's what we appear to be using. –  amurrell Aug 15 '13 at 15:29

1 Answer 1

up vote 0 down vote accepted

So I figured out a solution to this problem.

There are two ways I could fix it, one way is the way I asked on here - make a new interface to reflect the IP x.x.x.14.

Previously, I had defined a new Virtualhost to run SSL on the remaining domain. The problem is that defining the Virtualhost with one of our IPs isn't enough. We needed to relate that IP with one of our interfaces. Given that I am not familiar with writing interfaces, or creating virtual ones - and we already have complicated interfaces - this was not an easy route for me to go (no pun intended).

The way I fixed it was to run both Virtualhosts on the same IP address and Port - one of the IP addresses already related to a working interface. All I needed to do was add the NameVirtualhost directive, so that overlapping would not cause a warning with Apache. There was an excellent description of this here.

An example that the reference above provided demonstrates the idea, which I've adapted to fit my case:

NameVirtualHost x.x.x.12:433

<VirtualHost x.x.x.12:433>
ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
</VirtualHost>

<VirtualHost x.x.x.12:433>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>

We use apache's sites-available and sites-enabled, so each virtualhost is defined in its own respective file. I included the NameVirtualhost directive in just one of them and it worked.

Conclusion: I just used the same IP address that already had a working interface to avoid the trouble of figuring out how to make a new one.

share|improve this answer
    
I wanted to add that because we are using multiple SSL on 1 IP address now, that SNI (Server Name Indication) is being used... which SNI is not supported on windows XP. Running these two sites with SNI resulted with one of the sites' SSL certificate not working in IE 8 on windows XP. Since windows XP is not going to be maintained anymore by microsoft - we are not going to change this setup, but I thought that people should be aware of this in case they take this solution. –  amurrell Dec 10 '13 at 21:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.