2xNICs - separate routes - show same site on diff IPs

S

SupermanInNY

Verified User
Joined
Sep 28, 2004
Messages
428
[RESOLVED] - see below

Hi All,

I have a server that has a website that with a regular setting of apache, DNS etc.

My client now needs to have a new setting in the server:

On a different interface (NIC) we are running IPVPN solution. The NIC has an internal, IP (not true public) 10.255.255.1.

I need users who will use the IPVPN (intranet) to see the same site as the public IP one.

I need some suggestions on how to config the apache.conf (1.3.41) such that the same site will be available for users who surf using the public IP and for users who surf via the private network.

route add -net 10.255.255.0 netmask 255.255.255.0 gw 10.255.255.2
make sure you REMOVE gateway value from the interface of the IPVPN - in setup just don't have a value there, otherwise, big problem.
You can include the 'route add...' in /etc/rc.local so that it will remain after you reboot.


How do I set Apache to answer on two separate IPs for the same website.
Thanks for any help on this.

-Alon.
 
Last edited:
First you did not need the second NIC to do this. You could have added the private ip using the Ip Management system in DA.

Apache
This is what I do:

mkdir /etc/httpd/conf/vhosts
cp /usr/local/directadmin/data/users/username/httpd.conf /etc/httpd/conf/vhosts/username.conf

Change the ip's in /etc/httpd/conf/vhosts/username.conf to the private ip's and restart apache. Apache will now answer on both ip addresses for that user's domains.
 
floyd said:
First you did not need the second NIC to do this. You could have added the private ip using the Ip Management system in DA.

Apache
This is what I do:

mkdir /etc/httpd/conf/vhosts
cp /usr/local/directadmin/data/users/username/httpd.conf /etc/httpd/conf/vhosts/username.conf

Change the ip's in /etc/httpd/conf/vhosts/username.conf to the private ip's and restart apache. Apache will now answer on both ip addresses for that user's domains.
Click to expand...

Thanks for the quick reply.

Yes I did need the second NIC as the other network is provided to me via a separate physical network cable, so physically, there is no other way that I can do this.

As for the httpd.conf, I tried something in the meantime and I think it works:

I edited the /usr/local/directadmin/data/users/username/httpd.conf and just copied everything in it twice, so now I have duplicate records.
Since it has


<VirtualHost 1.2.3.4:80>

all regular stuff

</VirtualHost>

I copied it all and just changed the IP:

<VirtualHost 10.255.255.1:80>

all regular stuff

</VirtualHost>

Restarted apache, and now the site answers to both IPs.
Seems slightly shorter solution (I think :) ).

I've tested it using lynx.

lynx 10.255.255.1
lynx 1.2.3.4

from the server itself and both responded and pulled up the same site.
So I think that works fine :).

I now need to work with the data center and see if they can see the site.
I'm not sure how does name resolving works in an IPVPN environment.

-Alon.
 
Last edited:
I edited the /usr/local/directadmin/data/users/username/httpd.conf and just copied everything in it twice, so now I have duplicate records.
Click to expand...

And when you add another domain to that user all your changes will be gone. That is why I said to copy it to another directory. One thing I forgot to mention is that you also have to add:

Include /etc/httpd/conf/vhosts/*

to the main /etc/httpd/conf/httpd.conf file.
 
floyd said:
And when you add another domain to that user all your changes will be gone. That is why I said to copy it to another directory. One thing I forgot to mention is that you also have to add:

Include /etc/httpd/conf/vhosts/*

to the main /etc/httpd/conf/httpd.conf file.
Click to expand...

Thanks for the explanation. I'll follow that direction.

However, and this is the fun part, how do I set the nameservers in the zone files?

The same domain,. resolving to two different IPs.

what do I put in the zone files?

thedomainname.com. 14400 IN A 1.2.3.4
www 14400 IN A 1.2.3.4

If I replicate these lines: to:


thedomainname.com. 14400 IN A 1.2.3.4
www 14400 IN A 1.2.3.4
thedomainname.com. 14400 IN A 10.255.255.1
www 14400 IN A 10.255.255.1


Then only the 10.255.255.1 works and then the real IP doesn't work.

Any pointers with that?

Thanks,

-Alon.
 
tillo said:
You must have distinct resolution of the domain name for the two networks.
Use the view function of BIND: http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html
Click to expand...

Hi,

I've tried to implement the view option, but I'm obviously not doing it right :(.

Here is a typical /etc/named.conf file:


// Default named.conf generated by install of bind-9.2.4-2

acl "trusted" {
2.0.141.39;
10.255.255.1;
127.0.0.1;
};




options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";



version "not currently available";
allow-recursion { trusted; };
allow-notify { trusted; };
allow-transfer { trusted; };


};


include "/etc/rndc.key";

zone "oopsilon.com" { type master; file "/var/named/oopsilon.com.db"; };
...

############################

So now I've tried to add the VIEW option as shown in the following link: http://imrannazar.com/Intranet-DNS-Resolution-with-BIND-Views


view "internal" {
match-clients { 192.168.0.0/24; };
zone "oopsilon.com" IN {
type master;
file "oopsilon.zone.int";
allow-update { none; };
notify no;
};
};


view "external" {
match-clients { any; };
zone "oopsilon.com" IN {
type master;
file "oopsilon.zone";
allow-update { 2.0.141.39; };
notify yes;
};
};



The question is,. where do I stick this bit of code?

Is it before the zone "oopsilon.com" { type master; file "/var/named/oopsilon.com.db"; };

Do I need to remove the zone "oopsilon.com" { type master; file "/var/named/oopsilon.com.db"; }; ?

Everytime that I try to copy/paste it into the named.conf, and restart the named service, the service loads fine, but then, none of the domains resolve.
Not just the oopsilon.com domain, but any other domain,. all of them stop responding.

YES, I did create the oopsilon.zone and oopsilon.zone.int files in /var/named, so no errors on them.

So, if you know how to integrate it successfully into a DA modified named.conf,. I will be happy to learn how.



thanks,

-Alon.
 
[a WORKING SOLUTION - not pretty, but works]

Here is the named.conf that is in use with DA and VIEWs for Internal and External networks.
As you can see, the idea is to move all the domains such that they reside in the External block and include one (or more) in the Internal block.
I have not tested to see what would happen if I'm adding via DA another domain, will it keep it in the internal or external or put it into the end of the file which will keep it 'outside' of either the internal or external. In such an instance, I think it will not load it at all.


acl "trusted" {
62.13.11.30;
62.13.11.31;
62.41.141.39;
10.255.255.1;
127.0.0.1;
};

acl "lan_hosts" {
192.168.0.0/16; # network address of your local LAN
10.255.255.0/24;
127.0.0.1; # allow loop back
};


options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";



version "not currently available";
allow-recursion { trusted; };
allow-notify { trusted; };
allow-transfer { trusted; };


};





include "/etc/rndc.key";

view "internal" {
match-clients { lan_hosts; }; # match hosts in acl "lan_hosts" above
recursion yes; # allow recursive queries
notify no; # disable AA notifies

zone "thedomainiwantfromwithin.com" { type master; file "/var/named/thedomainiwantfromwithin.zone.int"; };

};


view "external" {

// "localnets" and "any" are special reserved words
// "localnets" mean any network address (as opposed to host address) configured
// on the local network interfaces - "!" means to negate
match-clients { !localnets; any; };
recursion no; # disallow recursive queries
// allow-transfer { dns_slaves; }; # allow "hosts in act "dns_slaves" to transfer zones

zone "server.myserver.com" { type master; file "/var/named/server.myserver.com.db"; };
zone "anotherregulardomain.com" { type master; file "/var/named/anotherregulardomain.com.db"; };
zone "someotherregulardomain.com" { type master; file "/var/named/someotherregulardomain.com.db"; };
zone "moredomains.com" { type master; file "/var/named/moredomains.com.db"; };
zone "bluedomain.com" { type master; file "/var/named/bluedomain.com.db"; };
zone "manyotherdomains.com" { type master; file "/var/named/manyotherdomains.com.db"; };
zone "thedomainiwantfromwithin.com" { type master; file "/var/named/thedomainiwantfromwithin.com.db"; };

};
 
Thank you for the research. Now I know where to look if I ever need this.
 
DirectAdmin WILL put it at the end.

Are you sure that won't enable it for everyone?

Jeff
 
jlasman said:
DirectAdmin WILL put it at the end.

Are you sure that won't enable it for everyone?

Jeff
Click to expand...

Hi Jeff,

What do you mean 'for everyone'?
Which part?
The External VIEW (the word VIEW is a reserved word) is for the 'everyone' or the 'public' IP/range.
DA might want to incorporate this into future releases. That would be nice to have.
I'm not sure how many folks actually need this feature enabled for them, I know I didn't need for this for 4 years until today.
With that said, it is easy to integrate and thus allow flexibility.
I've not added any other domains to the server, so I'm not really sure what will happen if I add another domain, Will it append it at the EOF or will it append it in the External zone section?
If it appends it to the EOF, AFTER the end of the External View section, then it goes into a 'blackhole'. It doesn't get recognized by ANY network, so that is obviously a non-favorable situation.
If this is employed via DA, then it would need to be appended/extracted from the 'External' view.

Hope that helps.

-Alon.
 
SupermanInNY said:
What do you mean 'for everyone'?
Which part?
The External VIEW (the word VIEW is a reserved word) is for the 'everyone' or the 'public' IP/range.
Click to expand...

Since DirectAdmin adds the next zone to the end of the file, it will be in neither the external nor internal view.

My understanding (maybe I'm wrong) is that if zones are outside of both views the zones will be served for all requests.
DA might want to incorporate this into future releases. That would be nice to have.

I'm not sure how many folks actually need this feature enabled for them, I know I didn't need for this for 4 years until today.
With that said, it is easy to integrate and thus allow flexibility.
Click to expand...

It's not quite that easy, because it requires the file be parsed and rewritten for every addition. But you're right in that it can be done.

That said one DirectAdmin user out of how many? Over four years? And of course it's easy enough to set it up manually.

Why don't you just write a plugin? :)

Also, be sure to check your work by adding a domain, adding an internal view (manually), and then deleting the domain. Make sure that DirectAdmin removes the public view and not just the first one it finds, which will be the internal view.
I've not added any other domains to the server, so I'm not really sure what will happen if I add another domain, Will it append it at the EOF or will it append it in the External zone section?
Click to expand...
My understanding is it will add at the end. You should check.
If it appends it to the EOF, AFTER the end of the External View section, then it goes into a 'blackhole'. It doesn't get recognized by ANY network, so that is obviously a non-favorable situation.
Click to expand...
Are you sure? While I've never used multiple views my understand has been that zones external to all views are served by the server without regard to view. I could be very wrong; you should definitely check.
If this is employed via DA, then it would need to be appended/extracted from the 'External' view.
Click to expand...
Which is a bit harder than you make it out to be.

Please check current behavior and let us know.

Perhaps you can post a link to BIND documentation explaining what happens to zones outside of all views.

Thanks.

Jeff
 
You must log in or register to reply here.
Back
Top