I have several virtual machines running on a server in network A. However, I need them to act as if they are part of network B (IP-s, hostnames, etc.). What is the best approach to this?
EDIT: QEMU + KVM for virtualization.
I think you need to take a look at a VPN network then. Then you can contact your servers as if they are in the same network.
Related
So a little background of what I'm trying to accomplish. I'm basically trying to setup a Windows File Server using GCP VM Windows Instance. I have the VM setup and I have created a VPN connection between our office network and to the GCP VM network.
Now I'm trying to communicate between the two different subnets and I have to admit I'm kinda lost.
My office subnet is 192.168.72.0/24 and my GCP IP is 10.123.0.0 with my server being at 10.123.0.2
If I understand networking correctly I need to setup a route between 192.168.72.0 to 10.123.0.2? Or do I just need to create a firewall rule?
I'm using a SonicWall Firewall to establish the VPN connection to the GCP network.
I think I've been working at this too long for one day. I'm steaping away for a bit.
Thanks in advance.
If you set up a Site to Site, you should not need to include a route, you will if you setup a Tunnel Interface. But to me, it sounds like you just need to do a site to site. I dont think the tunnel will come up without the correct subnets, but just verify that the tunnel is up and then I would setup a packet monitor to see what route the traffic is taking when you try to ping from 192.168.72.0/24 to IP is 10.123.0.0.
I'm struggling to understand if the reason for a host and virtual machines connection is through the internet, if it communicates with the host as an application would communicate with the PC it is installed on or if it uses a protocol like TCP (As it purpose is to connect 2 devices so they can exchange streams of data, so it would make sense that the VM and Host were connected by this protocol).
All answers are greatly appreciated :)
As by the definition of virtual machines, they run on a hosts hardware in virtually separate areas, so the host and Virtual machines do not share virtual memory and both systems can have completely different operating systems.
This means, that those two systems are completely separate and can be connected through a variance of interfaces - for example via a network connection (TCP/IP or UDP), if host and vm are connected directly to the network.
See here an article of VMWare about Host-only-Networking without the need of the WWW.
I have one or more virtual machines on Debian host and two physical eth interfaces. I want to split bandwidth between eths (both for downlink and one for uplink). Is it possible with openvswitch and openflow?
The short answer is that it should be possible with OVS and OpenFlow. With OVS you can connect your VM's virtual ports and the server's physical interfaces.
Without thinking too much, you can load balancing the traffic by:
Installing a flow to direct any VM packet to your uplink port. This flow should rewrite the src IP and MAC as the ones from the downlink interface, so that it will look like it is being sent through that port.
Keep in mind that you might take your virtual ports configuration into account, and that you need some kind of mapping (something like NAT), to get the packets correctly returned to its respective VM. You can take a look in a NAT implementation, for the Ryu controller, to get some inspiration.
I'm trying to establish a TCP connection between a client machine and a guest VM running inside an ESXi server. The trick is that the guest VM has no network configured (intentionally). However the ESX server is on the network, so in theory it might be possible to bridge the gap with software.
Concretely, I'd like to eventually create a direct TCP connection from python code running on the client machine (I want to create an RPyC connection). However anything that results in ssh-like port tunneling would be breakthrough enough.
I'm theorizing that some combination of VMWare Tools, pysphere and obscure network adapters could be possible. But so far, my searches don't yield any result and my only ideas are either ugly (something like tunneling over file operations) and/or very error prone (basically, if I have to build a TCP stack, I know I'll be writing lots of bugs).
It's for a testing environment setup, not production; but I prefer stability over speed. I currently don't see much need for high throughput.
To summarize the setup:
Client machine (Windows/Linux, whatever works) with vmware tools installed
ESXi server (network accessible from client machine)
VMWare guest which has no NICs at all, but is accessible using vmware tools (must be Windows in my case, but a Linux solution is welcome for the sake completeness)
Any ideas and further reading suggestions would be awesome.
Thank you Internet, you are the best!
It is not clear the meaning of 'no NICs at all on guest'. If I can assume that, there is no physical NICs assigned for the guest is what is meant here. The solution is easy as a vmWare soft NIC can be provisioned for the guest VM and that will serve as the entry point to the guest netstack.
But if the soft NIC is also not available, i really wonder how and what can serve as the entry point to the netstack of guest, be it Linux/Windows. To my understanding, if thats what you meant, then you might need to make guest OS modifications to use a different door to access the guest netstack and to post/drain pkts from it. But again, when you do a proper implementation of this backdoor, it will become just another implementation of softNIC which vmware by default support. So, why not use that?
It's a bit late but a virtual serial port may be your friend. You can pick the serial port on the outer end via network or locally depending on your options. Than you can have some ppp stuff or your custom script on both ends to communicate. You could also run some tool to create a single socket from the serial link on the guest end if you want to avoid having a ppp interface but still need to tunnel a TCP connection for some application.
This should keep you safe when analyzing malicious code as long as it's not skynet :-) You still should do it with the permission of the sysadmin as you may be violating your company's rules by working around some security measurements.
If the VM 'intentionally' has no network configured, you can't connect to it over a network.
Your question embodies a contradiction in terms.
A friend of mine told me there was a way to connect two private IPs without using a proxy server. The idea was that both computers connected to a public server and some how the server joined the private connections and won't use any more bandwidth.
Is this true? How's this technique named?
There is a technique called "Hole Punching" that works well with "Cone" NAT (Cone is a technical familly of router). That's not an 100% sure technique, today, it works well with UDP on about 80% of the router.
There is some implementations of library to realize Hole Punching: STUN (wikipedia)
This is true. It's the way FogCreek Copilot works
Take a look at item 2 on Joel's Copilot 2.0 post.
Your friend might be referring to VIP's (Virtual IP's). From my understanding a VIP is usually controlled by a piece of hardware like a router and then redirects to one of your 2 private IP's. We use this with a cluster of machines behind a VIP. I'm not a network guy so that's pretty much the extent of my knowledge.
If you're looking at joining two private networks (two networks of machines behind a NAT), the best way to do this is with a VPN. There are many pieces of equipment available to accomplish this.
I'm not sure it's what you're thinking of, but you could do something similar with ssh tunneling. Let's say you wanted userA on 10.1.2.3/24 to connect a mysql server on userB's on 192.168.0.3/24. There's no direct network connectivity between the two networks, but both machines can connect to serverA on the public internet.
userB runs this command:
ssh -R localhost:13306:localhost:3306 username#serverA
userA runs this command:
ssh -L 3306:localhost:13306 username#serverA
Now userA can use whatever tool they please to connect to mysql on localhost and the cxn will be tunneled through serverA and to the mysql daemon running on localhost on userB's machine.
(hopefully no typos, typed with one hand as I hold my two day old daughter =))