1 |
On Aug 29, 2013 7:46 PM, "thegeezer" <thegeezer@×××××××××.net> wrote: |
2 |
> |
3 |
> On 08/29/2013 01:12 PM, Randy Barlow wrote: |
4 |
> > Honestly, I think the best solution is to switch the company to using |
5 |
domain names to access these resources. This makes it much easier to |
6 |
silently introduce things like load balancers later on if you ever need to |
7 |
scale. It's also much easier to communicate to new users how to find this |
8 |
resource. Once you migrate to IPv6 it becomes a very long address to tell |
9 |
people as well. |
10 |
> > |
11 |
> > To answer your specific question, I would just do it with iptables if |
12 |
you must continue accessing it by IP address. I will point out that the |
13 |
service on the new IP address now has doubled its chances of going out of |
14 |
service, because it depends on both machines running, even though the first |
15 |
has nothing to do with it. Also, doing this with firewall rules isn't very |
16 |
nice from a systems management perspective for the future, as it's not very |
17 |
obvious what's going on with some server rewriting packets for another one. |
18 |
If someone sees that in two years, are they going to know what to do? What |
19 |
if they want to take server 1 down, and forget that it also disrupts 2? |
20 |
Using DNS is much cleaner for these reasons. |
21 |
> With iptables this could be tricky if everything is in the same LAN |
22 |
> subnet, you will need to ensure you have both DNAT and SNAT otherwise |
23 |
> you will have: |
24 |
> PC ---> serverA:3000 ---DNAT----> serverB |
25 |
> serverB ---replies---> PC |
26 |
> PC ignores packet "i wasn't talking to you, i was talking to serverA" |
27 |
> |
28 |
|
29 |
I do have some experience with double NAT-ting, but thanks for the reminder |
30 |
anyways :-) |
31 |
|
32 |
> Also bear in mind that from serverB's perspective, all connections on |
33 |
> port 3000 will appear to come from serverA. I know that a VT based |
34 |
> terminal server can set up users based on their originating IP, which |
35 |
> would previously have been a good detector of which terminal they are |
36 |
> connecting from. |
37 |
> |
38 |
|
39 |
Luckily, to the best of my knowledge, the apps do not make such |
40 |
distinction, so I can get away with such sleight of hand... |
41 |
|
42 |
> Rather than using iptables on serverA, you may like to consider EBtables |
43 |
> or IPtables on a server that sits in front of both serverA and serverB. |
44 |
> this would act as a bridge, and rewrite packets for serverA on port 3000 |
45 |
> to go to serverB on port 3000 |
46 |
> or |
47 |
> it could act as a router for NAT (iptables) if you change the ip subnet |
48 |
> of serverA and serverB, and make the NAT box have the original IP of |
49 |
serverA |
50 |
> this would allow connections by IP to be tracked |
51 |
> |
52 |
|
53 |
Interesting... I'll consider that. Although not strictly needed, tracking |
54 |
by IP will certainly be helpful. |
55 |
|
56 |
Thank you for the tip! |