I found that wireguard doesn't support dynamic IP configuration yet. That means that a configuration file for a peer can be used by only one device at a time, otherwise there would be a conflict of two devices in the network with the same IP.
It got me curious. How then VPN services that support wireguard work and provide VPN to many clients simultaneously? Even if wireguard doesn't support this feature yet.
I know about wg-dynamic development, but it's still not finished yet.
Related
My Hyperledger Fabric enironment is behind a firewall, and I have to establish a connection with another organization. I know that Hyperledger uses GRPC for communication, and my organization has a HTTP proxy to access the internet, and I don't know if HTTP proxy solves this problem.
Any idea?
IT teams of both the organizations need to open communication between each other. HTTP proxy is to cut your communication with actual internet. That is not going to work here, as both the orgs are individually controlled environments.
Once connectivity between orgs is established (like some n/w tunnel creation or something), you can work with the servers of the other org as if those are in your LAN. Your IT team should get involved here. All the best.
I'm running an app on Kubernetes / GKE.
I have a bunch of devices without a public IP. I need to access SSH and VNC of those devices from the app.
The initial thought was to run an OpenVPN server within the cluster and have the devices connect, but then I hit the problem:
There doesn't seem to be any elegant / idiomatic way to route traffic from the app to the VPN clients.
Basically, all I need is to be able to tell route 10.8.0.0/24 via vpn-pod
Possible solutions I've found:
Modifying routes on the nodes. I'd like to keep nodes ephemeral and have everything in K8s manifests only.
DaemonSet to add the routes on nodes with K8s manifests. It's not clear how to keep track of OpenVPN pod IP changes, however.
Istio. Seems like an overkill, and I wasn't able to find a solution to my problem in the documentation. L3 routing doesn't seem to be supported, so it would have to involve port mapping.
Calico. It is natively supported at GKE and it does support L3 routing, but I would like to avoid introducing such far-reaching changes for something that could have been solved with a single custom route.
OpenVPN client sidecar. Would work quite elegantly and it wouldn't matter where and how the VPN server is hosted, as long as the clients are allowed to communicate with each other. However, I'd like to isolate the clients and I might need to access the clients from different pods, meaning having to place the sidecar in multiple places, polluting the deployments. The isolation could be achieved by separating clients into classes in different IP ranges.
Routes within GCP / GKE itself. They only allow to specify a node as the next hop. This also means that both the app and the VPN server must run within GCP.
I'm currently leaning towards running the OpenVPN server on a bare-bones VM and using the GCP routes. It works, I can ping the VPN clients from the K8s app, but it still seems brittle and hard-wired.
However, only the sidecar solution provides a way to fully separate the concerns.
Is there an idiomatic solution to accessing the pod-private network from other pods?
Solution you devised - with the OpenVPN server acting as a gateway for multiple devices (I assume there will be dozens or even hundreds simultaneous connections) is the best way to do it.
GCP's VPN unfortunatelly doesn't offer needed functionality (just Site2site connections) so we can't use it.
You could simplify your solution by putting OpenVPN in the GCP (in the same VPC network as your application) so your app could talk directly to the server and then to the clients. I believe by doing this you would get rid of that "brittle and hardwired" part.
You will have to decide which solution works best for you - Open VPN in or out of GCP.
In my opinion if you go for hosting Open VPN server in GCP it will be more elegant and simple but not necessarily cheaper.
Regardless of the solution you can put the clients in different ip ranges but I would go for configuring some iptables rules (on Open VPN server) to block communication and allow clients to reach only a few IP's in the network. That way if in the future you needed some clients to communicate it would just be a matter of iptable configuration.
I am making a game in Libgdx where a user(client) will be a host of the server himself
and only one other client can connect to him and play with him(likewise there might be multiple independent servers and pair of clients playing with each other like miniclip games)
but how will the other client locate host-client (or servers) IP?
I am using kryonet
Some guy suggested me to do NAT punching and stuff but I am totally confused.
Please help
(I am complete beginner to networking)
If you want your clients to discover servers just in LAN, you can do broadcasting on the servers and sniffing on the clients. As they are in the same LAN, there should be no need for NAT.
Otherwise, you have to set up managers(servers for managing) on the Internet. Servers have to register themselves to a manager, clients ask a manager for servers information. As managers know both servers and clients public IP addresses, NAT should be easy once you think your managers as STUN servers.
The most simple manager can be just a simple wraper over database/Redis with a server name/server ip/server metadata table. Details about how to implement it relies on your skill stack. To enable STUN, there are open source STUN server and client you can just pick up, e.g. coturn. No matter you put the STUN server into your manager or not, both your managers and STUN servers have to be published on the Internet (sure include AWS) where they have their own public IP.
Or you can let the managers to relay messages for servers and clients. But this way may be too complicated compares to previous. I would not recommend.
I want to connect to a Cisco Anyconnect VPN (which I believe does NOT act as a proxy -- my IP address doesn't change when connecting to this VPN).
However I wish to hide my true IP to the Cisco Anyconnect server I'm connecting to.
Can I connect to another VPN service like TunnelBear first, then connect to the Cisco Anyconnect server, and be sure the Cisco Anyconnect server is seeing my TunnelBear proxy IP and not my real IP?
The scenario you are describing should be possible, using the technology you described. I would assume the sequence of events would follow:
Initiate OpenVPN connection
Initiate Cisco VPN connection
However, keep in mind that you may need to install a client to access the Cisco VPN. These clients tend to interact with and potentially manipulate your operating system's network configuration, this makes sense when you consider that these applications are built to re-route your network traffic. These clients would most likely have the ability to see your VPN configuration.
A possible workaround to the issues outlined above, regarding the local client being able to recognize your network configuration: one might configure their host's entire gateway (router or perhaps virtual machine host) to route traffic through the primary VPN.
You should keep in mind the resource usage and computation power required in order to maintain each VPN's security and (possibly) compression layers.
Even if the second VPN connection is established, I wouldn't expect quality performance, and multiple compression layers could be suboptimal.
I am trying to create a small academic project in the area of home automation. I explored various protocols and standards in IOT domain and find COAP close to my requirements.
The intent is pretty simple: To have a peripheral at home (like bulb, temperature sensor etc) which act as COAP server and expose certain resources and services. Since COAP uses an addressing scheme similar to web, any client having the address of this server shall be able to talk to this COAP server (i.e. peripheral) and control its attributes.
I have certain doubts about how a client not present in the same LAN as the server, can discover this server and the resources exposed by it. I understand that COAP facilitates resource discovery using CoRE link format but it seems that it primarily uses multicast which can only work within a LAN. I don't want to put a resource directory server at home and various COAP servers registering with it and then this directory server talking to a server sitting in the cloud. I want to have the ability to just install a peripheral at the home which can communicate to a remote client (like COPPER) using wifi home network. But how to discover the COAP server sitting at home from a remote location and then talk to it considering that COAP server will be on a private IP address.
Is this really possible using just COAP?
As you're sitting behind a NAT, that will allow neither direct discovery nor connections; CoAP will not try to magically pierce that.
Popular ways out are:
Use IPv6 (obliviating the use of a NAT) and (at least selectively) disable the firewall. You will still only be able to do discovery locally, but once discovered, you can connect to your devices from anywhere.
Use a VPN to make your mobile device act as if it were in the NAT.
Run a CoAP proxy at the router with a port open to the outside, and tell your mobile device to connect through that proxy. This does not give you local discovery either.
For the proxy and IPv6 cases, you can then still run a resource directory in your local network. That does neither need to connect to nor accept registrations from any cloud service, but it can help you do the very discovery that you'd like to do with multicast but can't because your mobile device is too far away. Both the resource directory and the proxy should be configurable to not talk to devices outside the local network unless they are authenticated.
Make your router accept HTTP requests , and run a HTTP to CoAP proxy in your system, access your CoAP devices via your IP thought HTTP-CoAP proxy.