Let us assume, I have hosted my Application on any cloud and want to migrate to AWS for the XYZ reason.
In the previous DATA centre, I have the public IP address assign for cloud VMs (Application).
Now if I'm migrating to AWS I want the same Ip address as the existing one.
So how we can achieve this as a network engineer.
CSP must ensure that the public IP address of cloud VMs remains the same even if the cloud VM network is being served from multiple CSP data centres.
There may be two situation
You want to change your cloud vendor. In this case, public IP can't be the same.
If you want to change the region to a single Cloud provider and use the same IP across all regions e.g; AWS.
then you have to create the Elastic IP with Global static IP addresses.
Related
I'm working on a migration plan in GCP where we have some VMs in a project that has its own VPC. We are setting up a Shared VPC and want to move the VMs to the new VPC. However, the system owners want to maintain the existing IPs (i.e. the VPCs each have the same subnet IP ranges). There are about 30 machines that need to be migrated so shutting everything off and migrating them would be challenging. The owners want us to migrate some of the VMs each day.
Of course, the current project has a VPN configured to connect the On-prem. When we stand up the VPN in the Shared VPC I believe that, alone, will cause problems, because the routes that are exchanged will cause the On-Prem to have two routes to the same subnet IP range.
Are there ways to configure the routes to tightly restrict this? For example, define routes for each IP as we move it from one VPC to another?
Scenario: The VMs are located in a Shared VPC.
Shared VPCs cannot have overlapping subnets. Therefore, you cannot migrate VMs between subnets and maintain the same private IP address.
Scenario: The VMs are located in independent VPCs.
You can allocate a private IP address when creating a new VM instance. Shut down the existing VM, create an image of the VM. Then create a new VM, reserve a static private IP address (under Primary Internal IP), and specify the image for the source boot disk.
However, you cannot specify overlapping or duplicate addresses for your VPN. This means that the migrated VMs will not be accessible to the VPN until you reconfigure the VPN.
My recommendation is to not even try to maintain the same private IP address. Migrate the VMs to the new VPC and reconfigure name resolution to use the new IP addressses.
We have a VPC which has VMs with private IP addresses only. There is no Cloud NAT attached to this VPC, so we should not be able to reach out public IPs.
Despite of the aboves, we experienced that we were able to curl the following public IP address from an internal VM.
64.233.166.153
The subnet of the VM has Private Google Access enabled and there is a default route to the default internet gateway, no other route entry matches for this IP. But there is no Cloud NAT.
My questions:
How is it possible to reach public IPs without NAT at all?
Are there other reachable public IPs? (without Cloud NAT)
What are these IPs used for?
Looks like the IP address belongs to a GCP resource/API.
As per GCP documentation[1], when PGA(Private Google Access) is enabled GCP VM instances without external IP can connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM's network interface.
This could be the potential reason why your VM was able to speak with the Public IP.
[1] https://cloud.google.com/vpc/docs/configure-private-google-access
Answer provided by #dp nulletla is right.
#Robert - For your use case that you mentioned in the comments - to reach BQ API from GCE with private IP without leaving google backbone network, I believe VPC Private Service Connect (PSC) for Google APIs is the right solution approach for you.
By default, if you have an application that uses a Google service, such as Cloud Storage, your application connects to the default DNS name for that service, such as storage.googleapis.com. Even though the IP addresses for the default DNS names are publicly routable, traffic sent from Google Cloud resources remains within Google's network.
With Private Service Connect, you can create private endpoints using global internal IP addresses within your VPC network. You can assign DNS names to these internal IP addresses with meaningful names like storage-vialink1.p.googleapis.com and bigtable-adsteam.p.googleapis.com. These names and IP addresses are internal to your VPC network and any on-premises networks that are connected to it using Cloud VPN tunnels or VLAN attachments. You can control which traffic goes to which endpoint, and can demonstrate that traffic stays within Google Cloud.
Basically when you create PSC endpoint,you assign private IP address to this endpoint. You reach respective google API e.g. Big Query, you always connect via PSC endpoint IP. This way you can control egress traffic in your VPC firewall rule with deny all and allow only PSC endpoint IP.
Additionally you can go 1 step further and try to restrict traffic/data going to BQ APIs from your GCE/VPC on more granular level with the use of VPC Service Control. By setting the VPC SC perimeter you can define/enforce with more restrictive policies to avoid any sort of data exfiltration.
Thanks
BR
Omkar
Networking newbie here. From the Documentation it feels like both NSG and Routing tables(UDR) are doing the same thing - capable of defining ACLs at multiple levels (Vnet, Subnet, VM)
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview
So how are they different and when is each used?
thanks.
Azure automatically creates a route table for each subnet within an Azure virtual network and adds system default routes to the table. The route table is like a networking map that tells the traffic from one place to another place via the next hop. This generates the "path" but does not filter traffic.
The Azure network security group is used to filter network traffic to and from Azure resources in an Azure virtual network. It contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. If there is no route to one place from a subnet, you even do not need to configure the security rules because there is no path. So when you consider the NSG it should have a successful network route.
For example, usually, we can access Azure VM in Azure virtual network via SSH or RDP over the Internet but it has a less secure way to expose the port 22 or 3389. We can restrict access to your Azure VM via specifying the source IP address in the NSG. This setting allows traffic only from a specific IP address or range of IP addresses to connect to the VM. Read more details here. In this scenario, we need to ensure that there is a route to the internet from your Azure virtual network and vice versa.
I'm developing an integration with an API which requires to whitelist customers based on IP addresses. I can easily get outbound IP from Production environments such as Azure or AWS and get those whitelisted.
How can I configure it for my desktop whose public IP keeps on changing after every few hours?
Getting a fixed IP address for your home computer is dependant on your internet provider. Sometimes they offer fixed IPs for 'Business' customers only or such.
Another solution might be to stand up an OpenVPN instance in your cloud then only whitelist that IP address and your expected partner prod addresses. Then you just connect to your VPN to access your API, you can do this from anywhere as your only dependant on the IP address of the cloud OpenVPN instance.
This solution also scales with your development as you only need to add new OpenVPN users to let other developers work with you and don't need their ever changing IP addresses.
I found an easy solution from NordVPN. It has an option to get a dedicated IP VPN :)
I have two environments on jelastic 4.7. On one of them I have a Java Stack and a Redis server that need to be kept private without a public IP address. On the other environment, I have a Node.js Stack that have a Public IP.
So, Im searching the docs exhaustively and can't find the answer to the question.
Can I access the private IP and port of my Redis from the node app?? Every node on Jelastic has a local ip address. Can I access those between environments??
I think it's a simple question. I'm trying to avoid the overhead of creating a public IP Address for Redis.
Can I access the private IP and port of my Redis from the node app??
Every node on Jelastic has a local ip address. Can I access those
between environments??
Yes, you can connect to different nodes of different environments using just a local IP within one hosting provider or its regions (depends on providers setup). Also, you can use Endpoints in order to connect to local IPs of other providers or to the regions within one provider, if direct connection can't be established.
Besides that, you can use, for example, CNAME of database instead of a local IP.