I have an API Management (premium) setup in Azure that is connected to a virtual network in West Europe that contains Docker Machines that serves APIs, the APIs are reachable via IP address in the 10.0.0/16 range.
To make my setup highly available I added a virtual network in North Europe with exactly the same setup as West Europe except for the IP range, now being 11.0.0.0/16.
Now when I scale API Management to add another region my APIs are not accessible anymore. I tried the set-backend-service command to only point to one region but I can't seem to access the backends anymore. The message that I get when doing the trace from the portal is "Unable to connect to the remote server". It seems to me that when adding another location that API management doesn't know how to route to the different virtual networks.
Any idea how I can make this setup work?
In multi-region scenario APIM runs same configuration in both regions. So for cases like yours you do need to use set-backend-service policy to conditionally override backend server address. So if your APIs at the moment setup with 10.0.X.X, you will need to add policy similar to below:
<choose>
<when condition="#(context.Request.Deployment.Region == "North Europe">
<set-backend-service url="http://11.0.Y.Y" />
</when>
</choose>
That is assuming that you address your backends by IP address. If you address them by DNS then you'll need to configure your DNS server in VNET to provide correct addresses.
The problem here was that the VNETs need to be peered. After I figured this out everything worked as advertised.
Related
I have a Python application which has been deployed to openshift.
I am using an external REST service in my application. In order to use this service, the developers of the REST service have to whitelist my IP because a Firewall blocks unauthorized IP addresses.
How can I find the external IP of my application? How can I find it in openshift? I tried a few OC commands, but I am not sure if I have to get the IP of the pod or the service.
Out of the box the traffic from internal cluster components will appear to external infrastructure like they are coming from whichever OpenShift compute host their pods are currently scheduled on.
Information on internal cluster networking and how traffic traverses from a process running inside a pod to the external network can be found at SDN: Packet Flow.
In your case you could have the external application whitelist all of the ip addresses of the compute hosts that are expected to run your application pods.
Alternately you could set up an EgressIP. This will cause all traffic originating from a specific OpenShift project to appear as if it is originating from a single ip address. You could then have your external application whitelist the EgressIP address.
Documentation for configuring EgressIP can be found in the official documentation under Enabling Static IPs for External Project Traffic
What you are searching for is the external IP of the Service. A Service acts as a load balancer for your pods but by default it only has a cluster-wide IP address. If you need a URL to access it from the outside, you can create a Route. For your purpose where you need an actual external IP address, you can assign the Service an external IP manually. Information on how to do this can be found in the official OpenShift Docs.
I'm trying to build a webserver in Google Cloud Platform that hosts multiple websites (GBP, IE, FR, DK etc.)
Generally, we assign a range of IPs to the server statically, set the bindings in IIS, then loadbalance using a virtual IP.
It seems near enough impossible to assign another internal IP in GCP. Lots of guides about additional external IPs, but we don't want a public facing webserver like this.
Anybody have any idea on how to add additional internal IPs to a VM / Instance?
Also, I have tried changing the internal address I have assigned to the Instance to static in network adapter settings, next thing I know I can't access my VM for love nor money, had to delete and re-create. If I go into advanced settings to add additional static IPs, w'ere set to DHCP apparently, so can't add additional IPs.
Thanks all.
Answer that I recieved from GCE discussion group, in Google Groups:
"You can add additional internal IP addresses to a VM instance. This is possible by enabling IP forwarding for the VM, creating a static network route, adding appropriate firewall rules, and setting additional internal IP addresses to network adapter of Windows. These steps are described in this article for Linux machines (https://cloud.google.com/compute/docs/networking#set_a_static_target_ip_address). The same steps are valid for Windows VMs. You will need to keep the initial internal IP address, subnet mask, gateway address and DNS settings of the adapter and manually enter them in properties of IPv4 of the network adapter. The below is a screenshot of my configuration on a VM instance (Windows 2008 R2) that perfectly works."
Update:
Now, you can create instances with multiple network interfaces On Google Compute Engine and assign IPs. For more information, refer to this public documentation link. However, currently it has following limitations:
Alias IP ranges are not supported on any network interface on a VM
that has multiple network interfaces enabled.
You cannot modify or delete the network interfaces after the VM has
been created.
I am using the Google Load-Balancer with the CDN option enabled.
When I setup the Backend Configuration for the load-balancer, I setup a backend with instances in US-Central, US-West and US-East.
Everything is working great, except all traffic is being routed only to the US-West backend service.
Does the load-balancer option route traffic to the closest backend service?
I see that there is an advanced menu in the load balancer for creating forwarding rules, target proxies and more.
Is there something I need to do to make my load-balancer load closest to client?
If they are in Florida and the CDN does not have the file, they get routed to the US-East VM Instance?
If that is not possible, it seems like having only an US-Central server would better than having US-Central, US-East and US-West? That way East Coast misses are not going to the West Coast to get the file. Everything will pull from the central location.
Unless there is a way to route traffic from the load-balancer to the closest VM instance, it seems as if the only solution would be to create different load balancers with the CDN enabled and use DNS routing to point to the CDN pool that is closest.
That setup would use 3 different CDN ip address's, 3 Compute Engine ip address's and dns latency or location routing. If they are in Florida, route them to the Google Load Balancer CDN in the east coast.
I'm not sure that would be a good solution on top of the Anycast ip routing. It seems like overkill.
Thank you for listening and any help or guidance would be appreciated.
"By default, to distribute traffic to instances, Google Compute Engine picks an instance based on a hash of the source IP and port and the destination IP and port."
Similar question: Google compute engine load balancing not routing properly Except all traffic in a live environment is all going to the same VM instance.
I am using the Google CDN Frontend Anycast ip address.
I think Elving is right and there may be a mis-configuration. Here is a screen shot of the VM instances in the Google Cloud. It says the two instances aren't in use.
Here is another picture of the Instances Groups. I don't see a clear way to make the instances attached to the instance groups.
The load balancer will automatically route traffic to the nearest instance group with capacity. You don't need to do anything other than configure your backend service to use multiple instance groups.
There's more information at https://cloud.google.com/compute/docs/load-balancing/http/.
I have just created cloud storage on google for mysql database.
I have added local IP address and server's IP address in authorization (under access control).
It's getting connected in mysql work bench in my local machine. But, it's not connecting with the website which is running on windows azure platform.
Which IP address am I supposed to use in access control?
Website is in basic package of azure.
This is a relatively non-trivial thing to achieve as the GCP services need to know about the public source IP of the Azure service. Azure's IP surface is pretty wide so you'd be unlikely to successfully connect the two. You'll be unlikely to be able use just a single source IP address.
You may be better off looking at a VPN connection out of an Azure VNet to your GCP environment.
To be honest, trying to build any form of performant web experience that hosts the web and data tiers in different public clouds is going to be extremely challenging.
Actually I resolved this issue by opening ticket in azure support.
They have outbound IP addresses range available online. We need to provide those IP addresses to third party access control.
I am sharing you that link here.
https://social.msdn.microsoft.com/Forums/azure/en-US/fd53afb7-14b8-41ca-bfcb-305bdeea413e/maintenance-notice-upcoming-changes-to-increase-capacity-for-outbound-network-calls?forum=windowsazurewebsitespreview
Choose those IP addresses which are associated with your website.
i need to know if the following scenario is possible using Google Cloud:
I need to have a IPSec VPN with a partner, the thing is that at their side they will allow only one of my hosts access their network, at their side they configure a ACL as follows: network-object host X.X.X.4.
So, is a must that in the negotiation of phase 2, Google Cloud send as local address the ip number allowed by their X.X.X.4, and not the network X.X.X.0/something, if that happens phase 2 will crash.
Is possible to configure the VPN using this requirement?
Regards,
Will.
You could try creating a /30 network in your project and hosts the VM that you would like to interact with the partner and setup the VPN tunnel
If you have another network, where other VM/Apps exists, setup a cross-vpn between the VPN tunnels in your project, just that they are in different network within the same project.