I have a server with a lot of interfaces, and only one interface is assigned IP address, this interface is kept for management.
but other interfaces are connected to the other server.
I want to know which interface is actually connected to the outside server.
Here, I tried to ping to the machine IP with particular interface ping -I eth1 x.x.x.x.
But not able to ping with the interface even though I know this is connected to the server.
All the packet is only going via the management eth0.
Is there a better way to find out which interface is connected to a particular machine?
I know the machine IP address
I am using ubuntu 18.04
Related
I need to create a TCP session "manually", without using the connect() function. I have tried to use RAW sockets. But in this case, I only get copies of the incoming IP packets. The original incoming packets slip through to the kernel and it generates an ACK response packet that damages my protocol.
Next, variant 2, I can write a virtual eth interface driver (kernel module) and route incoming traffic to it using iptables. But there is a patched non-original (non vanila) kernel on the machine. Normal linking of the module with the kernel is not possible.
Variant 3. I also tried not to assign an IP address to the NIC interface. In this case, the network TCP/IP layer module in the kernel is not activated and it is possible to generate and receive arbitrary IP packets on the link (ethernet) layer using the PF_PACKET socket domain type in the socket() function. But at this time, any other applications using the TCP/IP protocol can’t work.
How can this problem be solved in other ways?
It would be nice if it were possible to intercept packets going from the network interface to the kernel, that is, intercept the SKBuf buffer. But I don't know how to realize it.
Apparently you are trying to create a tunnel. Instead of trying to hijack an existing interface, the proper way to create a tunnel is to create a new interface, using a kernel module or TUN/TAP. However, tunnels are normally intended to receive traffic generated on the machine which runs the tunnel software, or at least routed through it. That means you will also have to set up the kernel to route the traffic to your tunnel.
You can create a new interface as a TUN/TAP interface. It is like a virtual ethernet driver except you don't need to write a new kernel module. It is designed for tunnels (hence the name).
The difference between TUN and TAP is that a TUN interface is an IP interface that receives IP packets from the kernel's IP routing system, and a TAP interface receives Ethernet packets (which may contain IP packets) so it can alternatively be part of a bridge (a virtual Ethernet switch - which only looks at the Ethernet header, not the IP header).
I think for your scenario, you will find it easiest to create a TAP interface, then create a bridge (virtual Ethernet switch) between the TAP interface, and the interface which the other host is connected to. Neither one needs an IP address - the kernel will happily pass Ethernet-layer traffic without attempting to process the IP information in the packet. Your tunnel software can then emulate a host - or tunnel to an actual host - or whatever you want it to do.
Or in visual form:
If you want the host to also be able to talk to the machine running the tunnel software - without going through the tunnel software - then you may choose to put an IP address on the bridge.
I have a local Linux machine (L), with a network interface (eth0) connected to (currently) only one device (D).
L/eth0 only has an ipv6 link local address.
D also only has an ipv6 link local address.
Client software on L discovers D's link local address by sending a custom multicast packet over eth0. The response contain the device link local address as well as some configuration information. From there it communicates with the device using various UDP or TCP port.
My goal is to be able to use the device from a remote machine (R). The remote machine being most likely a Linux docker container running on some host - although it could be a native macOS or other.
That means running both the discovery protocol and communicate with the device. I definitely cannot modify software on the device, and cannot modify most of the client software running on the local Linux or remote machine (Limited modification could possibly be requested)
My idea was to somehow create a virtual interface on the remote machine, that would remotely be bridged to the the local machine, so that the multicast discovery works from the remote, and so that I can just connect to D link local address from the remote.
I'm not sure which tool(s) I should be using.
I'm googling various things about VPN and tunnel, TUN/TAP interfaces, bridges, VETH, VLAN, etc... but I'm having trouble connecting the dots here... I have no budget for this, so I'm looking for open source tools, or just something I can cobble up together with common tools.
Thanks
I like to connect to a TCP server that run in a machine that is connected to the LAN in my home network. This LAN can be connected to internet via either following methods.
1. Through a router which has a wireless or wired WAN connection
2. Through a router which uses a mobile broadband connection, for example a router that accept a USB modem to connect to internet.
I know in the first case, we can use port forwarding.
In the second case, I believe telcos use PPP protocol and port forwarding does not work.
In addition, even in the first case, if ISP does not give a static IP, then we need to use DNS mapping service to map a fixed URL to the allocated dynamic IP and we need to configure router to go and register the dynamic ip at the start up.
My question is, are there any other better methods that can be used in this situation? I am wondering how chat applications connect to each other? I hope they maintain a TCP connection between two devices, without a central relay server?
I'm using ZeroMQ on Windows, using C#, and am confused by a very basic networking question. I set up simplistic sample programs, one to PUBlish messages, the others use a SUB socket to receive them (the SUBscriber programs).
Works fine when both are on the same box. I used endpoint tcp://127.0.0.1:5000
As the next step, I put the SUBscriber program on a separate virtual machine (VM), to simulate using separate computers. I ran ipconfig to get it's IP address (on the guest os), 192.168.92.136
The host os has several network interfaces, one of which is the VMware Network Adapter VMnet1, with IP 192.168.92.1
On the host os, I ran the PUB program and connected the socket to 192.168.92.136, the IP address of the guest os.
On the guest os, I ran the SUB program and connected the socket to the IP of the host os. Did not work.
Then I changed the SUB program on the guest os to make it connect it to it's own IP address, ie that of the guest os - 192.168.92.136. Now it works!
Question: Why? I'm confused. But in a way it sort of makes sense: if that socket is for a service that attends to various clients that dynamically come and go, it doesn't know the IP address of each client. Therefore what the heck do you specify as the IP address for the SUB socket?! So connecting it to it's own host IP address does solve that concern. But the ZeroMQ Guide doesn't say this anywhere!
A related question is: if your host has multiple network interfaces, and each has it's own IP address, then if you connect your socket to some other host using the IP address of that other host - do you not need to specify which of those network interfaces you want to connect through? If so, how?
Incidentally, only one subscriber program seems to be able to connect at a time. The 2nd program to attempt to connect to it's SUB socket to the local IP address always gets a "Address is in use" error-message. I'm trying to make progress in small steps and learn this as I go.
Thanks for any help or advice.
James Hurst, JamesH at Designforge dot com
I have two servers, written in Java, that communicate through sockets and TCP. The servers are both on the same Linux machine. If the servers were on different machines then data would have to go through network adapters and network cables, but since the servers are on the same machine how does the OS actually move data efficiently form one server to the other.
Generally, the messages will be sent over the loopback interface:
In TCP/IP a loopback device is a virtual network interface implemented in software only and not connected to any hardware, but which is fully integrated into the computer system's internal network infrastructure. Any traffic that a computer program sends to the loopback interface is immediately received on the same interface.
However, you can manage to configure your situation so that, for example, the server is referred to via an external IP address so that messages actually go out over the network before being routed back to the same machine.
If two programs are using TCP/IP to communicate on the same machine, they are probably connected through the loopback interface