I have an ios app that needs an API to works yet this API is deployed using Kubernetes that doesn't support IPv6 for now.
I am intending to create proxy server that do the redirection of packets to the actual api. How could be done using google compute engine? A load balancer?
You do not need a proxy but a reverse-proxy. Therefore, yes a load balancer is a way to comply to your need. Do not forget to configure the DNS with the IPv4 and IPv6 addresses of the load balancer.
But when you say I have an ios app that needs an API to works [...] support IPv6. If what you are saying is based on the fact that Apple wants iOS apps in their store to support IPv6, note that having an IPv6 server is not compulsory. Apple expects your client application to work correctly when connected to an IPv6-only network, but that IPv6-only network MUST help your application by offering a DNS resolver that is DNS64 compliant and also offering a NAT64 IPv6-to-IPv4 translation gateway. This means your client application makes a DNS request to www.myipv4onlyserver.com and the resolver replies with a fake IPv6 address routed to a NAT64 gateway. Thus, your client application talks with IPv6 to this gateway and this gateway translates the data channel to your IPv4 server, like a transparent proxy.
So, to be compliant with Apple expectations, if you only use high-level network libraries and address-agnostic APIs, such as getaddrinfo() and getnameinfo(), then you do not need to support IPv6 on the server side.
At the moment, GCE instance don't support IPv6, so you cannot terminate IPv6 on an instance or set up the (reverse) proxy yourself.
However Google Cloud HTTP(S), SSL and TCP proxy do support IPv6. You could use this to accept IPv6 connections and forward them to your GKE nodes. It might even be possible to do this with the HTTP LB created as part of a Kubernetes Ingress, and thus have it automatically connected to the correct pods.
Related
I have a WebSocket server running on an Android device on my local network. I would like to have the ability to discover this server using DNS-based Service Discovery (DNS-SD). I believe this is possible for plain sockets but is this possible for WebSockets? If not, are there any other mechanisms besides DNS-SD that would allow me to discover a WebSocket server on a LAN besides iterating through all possible IP:port combinations? If this is possible, how can I go about naming my service so that it is discoverable?
Browsers leaks Public IP through WebRTC protocols while routing traffics through browser specific proxies such as chrome vpn extensions. but using Native VPN Application (OS Specific) doesn't produce public ip through WebRTC.
How to overcome this problem and force chromium to use proxy IP instead of public IP for WebRTC communication.
Note- Blocking WebRTC from Browser does hide the public ip but many websites eg. google.com, godaddy.com treats you as a bot and blacklist you from using some of their services.
This issue is more related to browser fingerprinting than ungoogling stuffs..
No Extensions available to solve this problem till now but some of the automation tools such as Kameleo.com is able to do such things but those are pricy.
Possible solutions
Force chromium to use proxy ip through ICE Framework TURN/STUN signaling services
I also don't know how to seup STUN connection so please also guide me for the coding part.
https://isaacbrains.com
TLDR: Configure and deploy your own TURN server and configure your WebRTC app to use relay candidates only via iceTransportPolicy and use only TURN for your iceServers.
Something like this:
let config = {
iceServers: [{urls: "turn:turn.yourdomain.com:3478"}],
iceTransportPolicy:"relay"
};
WebRTC does not use browser proxies. Browser proxies bridge connections via http/https to websites. And browser proxies don't fit into the model WebRTC uses to connect to another client ad-hoc packet transfer of UDP packets.
STUN exists primarily for clients to discover and share their own public IP address and port mapping. It sounds like you want to avoid STUN since you don't want srflx candidates anyway.
TURN is a relay server protocol for WebRTC, VOIP, and other types of P2P connections. It's primary job is to be a fallback when direct client to client communication is not possible. But it sounds like you want to avoid that altogether and just have the SDP advertise your relay (TURN) addresses only.
I've seen a lot of documentation and tutorials how to setup HTTPS and Websockets on heroku, but it's possible to setup another protocol like TLS or NATS?
If it's possible how can I do that?
Unfortunately, no.
Inbound requests are received by a load balancer that offers SSL
termination. From here they are passed directly to a set of routers.
The routers are responsible for determining the location of your
application’s web dynos and forwarding the HTTP request to one of
these dynos.
https://devcenter.heroku.com/articles/http-routing#routing
Not supported
TCP Routing
https://devcenter.heroku.com/articles/http-routing#not-supported
Heroku offers only http/https routing for applications hosted on it.
We have two applications running on ibm cloud cloud foundry (appA and appB).
appA is accessing appB over a container-to-container networking while appB is also available externally over a Gorouter route.
The thing is that while it is http-8080 our app exposes - all is good.
Now we have to do container-to-container networking over https.
We configured the app to expose https-8080. 8080 is used as https://docs.cloudfoundry.org/devguide/custom-ports.html states that:
By default, apps only receive requests on port 8080 for both HTTP and TCP routing,
and so must be configured, or hardcoded, to listen on this port
container-to-container networking works as expected now using https.
But we are no longer able to use the appB over the external Gorouter route.
What is the best way to have it all up and running as we expect?
There isn't a good answer to this question, at least at the time I write this.
You do have a couple options though:
Manually set up HTTPS for the internal route. To do this, you would need to use the instructions for your application/server of choice to configure HTTPS. Then use whatever functionality your buildpack provides to inject this confirmation into the application container. This would also require you to bundle and push TLS certs with your application. The platform isn't going to provide you TLS certs if you take this option.
The trick to making both the internal and public route work is that you need your application to listen on both port 8080 and the port you choose for your HTTPS traffic. As long as you continue taking HTTP traffic on port 8080, then your public routes should keep working.
If you want a quick, but not ideal solution you can use port 61001. For newer versions of Cloud Foundry, this port is used by Envoy to accept traffic to your app over HTTPS. Envoy then proxies the request to your app via HTTP over port 8080. You can use this port for your container to container traffic as well, however the configured subject name on the TLS cert won't match your route.
Here's an example of what the subject name will look like.
subject: OU=organization:639f74aa-5d97-4a47-a6b3-e9c2613729d8 + OU=space:10180e2b-33b9-44ee-9f8f-da96da17ac1a + OU=app:10a4752e-be17-41f5-bfb2-d858d49165f2; CN=b7520259-6428-4a52-60d4-5f25
Because it's using this format, you would need to have your clients ignore certificate subject name match errors (not ideal as that weakens HTTPS), or perhaps create a custom hostname matcher.
For what it's worth, I don't think you want or need to change the port. That is typically used if your application is not flexible and unable to listen on port 8080. It changes the port for inbound traffic. Since you're only using C2C networking, you don't need that option.
What you want, from what I understand, is that you want HTTPS for C2C traffic. In that case, the public traffic doesn't matter. It can still go through Gorouter to port 8080. For your container-to-container traffic, you can pick any port you want. You just need to make sure the port you choose has network policy set to allow that traffic (by default all C2C traffic is blocked). Once the network policy is set, you can connect directly over whatever port you designate.
We are hosting an application in the preprod azure PCF environment which exposes websocket endpoints for client devices to connect to. Is there a prescribed methodology to secure the said websocket endpoint using TLS/SSL when hosted on PCF and running behind the PCF HAProxy?
I am having trouble interpreting this information, as in, are we supposed to expose port 4443 on the server and PCF shall by default pick it up to be a secure port that ensures unsecured connections cannot be established? Or does it require some configuration to be done on HAProxy?
Is there a prescribed methodology to secure the said websocket endpoint using TLS/SSL when hosted on PCF and running behind the PCF HAProxy?
A few things:
You don't need to configure certs or anything like that when deploying your app to PCF. The platform takes care of all that. In your case, it'll likely be handled by HAProxy, but it could be some other load balancer or even Gorouter depending on your platform operations team installed PCF. The net result is that TLS is first terminated before it hits your app, so you don't need to worry about it.
Your app should always force users to HTTPS. How you do this depends on the language/framework you're using, but most have some functionality for this.
This process generally works by checking to see if the incoming request was over HTTP or HTTPS. If it's HTTP, then you issue a redirect to the same URL, but over HTTPS. This is important for all apps, not just ones using WebSockets. Encrypt all the things.
Do keep in mind that you are behind one or more reverse proxies, so if you are doing this manually, you'll need to consider what's in x-forwarded-proto or x-forwarded-port, not just the upstream connection which would be Gorouter, not your client's browser.
https://docs.pivotal.io/platform/application-service/2-7/concepts/http-routing.html#http-headers
If you are forcing your user's to HTTPS (#1 above), then your users will be unable to initiate an insecure WebSocket connection to your app. Browsers like Chrome & Firefox have restrictions to prevent an insecure WebSocket connection from being made when the site was loaded over HTTPS.
You'll get a message like The operation is insecure in Firefox or Cannot connect: SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS. in Chrome.
I am having trouble interpreting this information, as in, are we supposed to expose port 4443 on the server and PCF shall by default pick it up to be a secure port that ensures unsecured connections cannot be established? Or does it require some configuration to be done on HAProxy?
From the application perspective, you don't do anything different. Your app is supposed to start and listen on the assigned port, i.e. what's in $PORT. This is the same for HTTP, HTTP, WS & WSS traffic. In short, as an app developer you don't need to think about this when deploying to PCF.
The only exception would be if your platform operations team uses a load balancer that does not natively support WebSockets. In this case, to work around the issue they need to separate traffic. HTTP and HTTPS go on the traditional ports 80 and 443, and they will route WebSockets on a different port. The PCF docs recommend 4443, which is where you're probably seeing that port. I can't tell you if your platform is set up this way, but if you know that you're using HAproxy, it is probably not.
https://docs.pivotal.io/platform/application-service/2-8/adminguide/supporting-websockets.html
At any rate, if you don't know just push an app and try to initiate a secure WebSocket connection over port 443 and see if it works. If it fails, try 4443 and see if that works. That or ask your platform operations team.
For what it's worth, even if your need to use port 4443 there is no difference to your application that runs on PCF. The only difference would be in your JavaScript code that initiates the WebSocket connection. It would need to know to use port 4443 instead of the default 443.