GCP Memorystore host discovery and CNAME - google-cloud-platform

With AWS Elasticache, the connection host is returned as a CNAME (for example mycluster.1abc4d.0001.usw2.cache.amazonaws.com)
I am using GCP App Engine With GCP Memorystore.
It looks like Memorystore Redis returns an IP to an instance, rather than a CNAME.
Is this IP forever fixed? (What happens when clusters are added/removed?)
Is there any way to discover this IP for this host?
Should we have any concerns with using the IP directly? Or is there any settings that I can turn on to get a CNAME back from GCP that points to the Redis instance?

Just so you know Memorystore for Redis supports two connection modes, direct peering and private service access. Regardless of the connection mode, Memorystore for Redis always uses internal IP addresses to provision Redis instances.
Is this IP forever fixed? (What happens when clusters are added/removed?)
Yes, there are no specific events that would cause the IP address of a running Redis instance to change except the deletion of the Instance
Should we have any concerns with using the IP directly?
You should not have any concerns using IP directly, however to improve your security and facilitate your IP management it is strongly suggested that you use Private services access
Is there any settings that I can turn on to get a CNAME back from GCP that points to the Redis instance?
Yes, you can create a CNAME record using our service Cloud DNS to points to your Redis instance

Related

GCP Kubernetes block IP address?

What is the standard way to block an external IP from accessing my GCP cluster? Happy for the answer to include another Google service.
Because your cluster is deployed on Compute Engine instance, you can simply set a firewall rule to discard connection from a specific IP.
If you use an HTTP load balancer, you can add Cloud Armor policy to exclude some IPs.
In both case, keep in mind that IP filtering isn't very efficient. A VPN or Proxy can be easily and freely used on the internet and change the IP source of the requester.

Compute Engine in VPC can't connect to Internet & Cloud Storage after establishing Cloud VPN

Assuming I have a custom VPC with IP ranges 10.148.0.0/20
This custom VPC has firewall rules to allow-internal so the service inside those IP ranges can communicate to each other.
After the system grows I need to connect to some on-premises network by using Classic Cloud VPN, already create Cloud VPN (the on-premises side configuration already configured by someone) and the VPN Tunnel already established (with green checkmarks).
I also can ping to on-premises IP right now (let's say ping to 10.xxx.xxx.xxx where this is not GCP internal/private IP but on-premises private IP) using compute engine created on custom VPC network.
The problem is all the compute engine instance spawn in custom VPC network can't communicate to the internet now (like doing sudo apt update) or even communicate to google cloud storage (using gsutil), but they can communicate using private IP.
I also can't spawn dataproc cluster on that custom VPC (I guess because it can't connect to GCS, since dataproc needs GCS for staging buckets).
Since I do not really know about networking stuff and relatively new to GCP, how to be able to connect to the internet on instances that I created inside custom VPC?
After checking more in-depth about my custom VPC and Cloud VPN I realize there's misconfiguration when I establish the Cloud VPN, I've chosen route-based in routing option and input 0.0.0.0/0 in Remote network IP ranges. I guess this routes sending all traffic to VPN as #John Hanley said.
Solved it by using policy-based in routing option and only add specific IP in Remote network IP ranges.
Thank you #John Hanley and
#guillaume blaquiere for pointing this out

How can I use AWS load balancer to check IP changes?

I have an instance running on premise and its IP address is changed regularly. My other services are running on AWS and they are using IP to connect to the premise's services. I have to update the IP address saved on AWS services whenever the IP is changed on premise network. I have a thought about using DNS but it is still a need to update A record.
I am looking for a way to do some auto-detect instead of manual updating. I wonder whether I can use load balancer to do the check. I know there will be a range of IP addresses on premise network. Can load balancer do a health check on these IP within the range? So my AWS service can send request to the load balancer. Is there any side-effect on this approach?
You need to use hostname instead of IP address as you mentoned the IP addresses keeps changing. AWS VPC can use a DNS forwarder like Unbound, which can forward the requests to your on premise DNS server when VPC resolution is unable to resolve the hostnames. This appraoch is quite effective as you send only those DN resolution to on-premise DNS that are missed by AWS VPC DNS.
Unbound allows resolution of requests originating from AWS by
forwarding them to your on-premises environment—and vice versa. For
the purposes of this post, I will focus on a basic installation of
Amazon Linux with the configuration necessary to direct traffic to
on-premises environments or to the Amazon VPC–provided DNS, as
appropriate. Review the Unbound documentation for details and other
configuration options.
Further reading : How to setup DNS resolution from AWS to on premise servers

Unable to telnet to GCP MemoryStore

I have created an instance of the Memory store in my project but I am unable to telnet / connect to it, either from my local or the Google Cloud Shell. Searching online, I see that other people have been granted the same host IP as mine so I am a little confused (10.0.0.3). Some assistance on how to proceed here would be great. Do I have to expose something here?
I have completed the following:
Recreated my VM on the same region as the memory store
Created a new instance of the memory store (gave me a new IP) but I am still unable to telnet
You can connect to Cloud MemoryStore provided that you are in the same project, region and network. If any of these are different you will not be able to connect.
The IP address 10.0.0.3 is an RFC 1918 private address. This is why you must be in the same network to be able to connect. Also you need to enable firewall rules to allow traffic between your instance and Cloud Memorystore.
This link shows you how to connect to Cloud Memorystore from a GCE instance.
Connecting to a Redis Instance

Unable to connect to azure vm with internal IP

I have two vnets that are connected using a gateway. VnET1 and VNET2. VNET2 has a VM which hosts a mongodb instance. I have a webjob running within an App service environment which is deployed into a subnet within VNET1. From this subnet i am able to access the VM in VNET2 with its DNS. But i am unable to access the VM's internal IP. Any suggestions are welcome.
An internal IP address is internal to a VNET, and VNETs are isolated from one another by design. See this site for a good overview.. https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-overview/. If you want to connect internally you might want to consider having multiple subnets within the same VNET instead.
At present, connecting two vnets using a gateway allows IP communication but doesn't allow DNS name resolution. In this scenario we recommend managing a local DNS server. This page shows the requirements for using your own DNS server in Azure.
Hth, Gareth