Isolating server nodes to a fixed virtual IP or interface

classic Classic list List threaded Threaded
3 messages Options
Gilles Gilles
Reply | Threaded
Open this post in threaded view
|

Isolating server nodes to a fixed virtual IP or interface

Hello,

I'm currently moving a project from development stage to production. The aim is that my cluster server nodes are running on multiple virtual private servers, inside a VPN (10.0.0.0/24).

But how do I make sure that I lock any communication of a node to either a specific network interface, or a static virtual IP (eg 10.0.0.3)?

Some googling got me to this answer from old documentation.

<property name="communicationSpi">
            <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
              <property name="localAddress" value="10.0.0.3"/>
            </bean>
 </property>

However the nodes are still accessible on their public IP addresses. So the question is, what is the correct way to isolate them from the public?

I will be using a software firewall on these servers too, but I like to have the peace of mind from the extra layer of security.


Thanks in advance,
Gilles

And to the creators, maintainers and contributors, thank you so much for this great piece of software! Never had so much fun doing "cumbersome" database work.



dmagda dmagda
Reply | Threaded
Open this post in threaded view
|

Re: Isolating server nodes to a fixed virtual IP or interface

Hi Gilles,

Thanks for considering Ignite for your project! Let's help to get you to production avoiding bumpy roads )

Try to set the 'localAddress' parameter (and 'localPortRanges' if needed) for both the discovery and communication settings:

On Thu, Oct 22, 2020 at 10:54 AM Gilles <[hidden email]> wrote:
Hello,

I'm currently moving a project from development stage to production. The aim is that my cluster server nodes are running on multiple virtual private servers, inside a VPN (10.0.0.0/24).

But how do I make sure that I lock any communication of a node to either a specific network interface, or a static virtual IP (eg 10.0.0.3)?

Some googling got me to this answer from old documentation.

<property name="communicationSpi">
            <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
              <property name="localAddress" value="10.0.0.3"/>
            </bean>
 </property>

However the nodes are still accessible on their public IP addresses. So the question is, what is the correct way to isolate them from the public?

I will be using a software firewall on these servers too, but I like to have the peace of mind from the extra layer of security.


Thanks in advance,
Gilles

And to the creators, maintainers and contributors, thank you so much for this great piece of software! Never had so much fun doing "cumbersome" database work.



ilya.kasnacheev ilya.kasnacheev
Reply | Threaded
Open this post in threaded view
|

Re: Isolating server nodes to a fixed virtual IP or interface

In reply to this post by Gilles
Hello!

Have you also tried setting IgniteConfiguration.localHost property?

Regards,
--
Ilya Kasnacheev


чт, 22 окт. 2020 г. в 20:54, Gilles <[hidden email]>:
Hello,

I'm currently moving a project from development stage to production. The aim is that my cluster server nodes are running on multiple virtual private servers, inside a VPN (10.0.0.0/24).

But how do I make sure that I lock any communication of a node to either a specific network interface, or a static virtual IP (eg 10.0.0.3)?

Some googling got me to this answer from old documentation.

<property name="communicationSpi">
            <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
              <property name="localAddress" value="10.0.0.3"/>
            </bean>
 </property>

However the nodes are still accessible on their public IP addresses. So the question is, what is the correct way to isolate them from the public?

I will be using a software firewall on these servers too, but I like to have the peace of mind from the extra layer of security.


Thanks in advance,
Gilles

And to the creators, maintainers and contributors, thank you so much for this great piece of software! Never had so much fun doing "cumbersome" database work.