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
Related
I am trying to get a Windows Server EC2 instance to communicate with a running Kubernetes Service. I do not want to have to route through the internet, as both the EC2 Instance and Service are sitting within a private subnet.
I am able to get communication through when using the private IP address of the Service, but because of the nature of Kubernetes when the Service goes down, for whatever reason, the private IP can change. I want to avoid this if possible.
I either want to communicate with the service using a static private DNS name or some kind of static private IP address I can create and bind to the Service during creation. Is either of this possible to do?
P.S. I have tried looking into internal LoadBalancers, but I can't get it to work. Don't even know if this is the right direction. https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/service/annotations/#traffic-routing. Currently I am using these annotations for EIP binding for some public-facing services.
Why not create a kubeconfig to access the EKS services through kubectl?
See documenation: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html
or you want to send traffic to the services?
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
I created an instance on GCP, but I am not able to access it.
This is similar to this one, but the proposed solution isn't working for me:
Unable to telnet to GCP MemoryStore
I have tried to telnet to it, I am in the same project and region, but apparently I need to be in the same network as it's a private ip, but what if you want to connect using the cloud shell? Also, how would an application running on my local machine access it?
I also included a firewall rule to make sure incoming connections are allowed.
To connect a client to a Cloud Memorystore for Redis instance, the client and the instance must be located in the same region, in same project and in the same VPC network. Please check the “Networking” document where you’ll have information on Basic network settings, limited and unsupported networks, network peering, IP address range.
You can connect to Redis from different GCP products like Compute Engine VM, Google Kubernetes Engine Cluster or Google Kubernetes Engine pod, but you can’t connect directly from the Cloud shell or from your local machine since they are not in your VPC network.
It may also have to do with a missing peering connection to your network. Check in your console at https://console.cloud.google.com/networking/peering/ to see if the peering is set up properly.
Using terraform you can use the following docs: https://www.terraform.io/docs/providers/google/r/redis_instance.html
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
I am taking the Google's GCP Fundamentals: Core Infrastructure course on Coursera. In the demonstration video of the Google Storage module, the presenter authorizes a compute engine instance to access a MySQL instance via it's external IP address.
Aren't these two resources part of the same VPC if they are part of the same project ? Why can't this authorization be done using the vm instance's internal IP address ?
Aren't these two resources part of the same VPC if they are part of
the same project ?
A Cloud SQL instance isn't created in one of your project's VPC network but in a Google-managed project, within its own network.
What happens when you enable private IP is that this network will be peered with the network of your choice in your project, where your Compute Engine instance resides:
You can then connect to the Cloud SQL instance from your VM via the internal IP address. The VM is considered trusted if your network configuration allows it to reach the Cloud SQL instance.
When you set an external IP address on the Cloud SQL instance, it means that the instance is accessible to the internet and the connection needs to be authorized. One way to do it is to whitelist the IP address of the caller as you mentioned. This works well if the caller's IP doesn't change. Another (easier) option is to connect via the cloud_sql_proxy, which handles authorization and encryption for you. You then don't need to whitelist the IP.