I'm not clear about how the tun/tap interface is working. From Wikipedia, I got this:
Packets sent by an operating system via a TUN/TAP device are delivered to a user-space program that attaches itself to the device. A user-space program may also pass packets into a TUN/TAP device. In this case TUN/TAP device delivers (or "injects") these packets to the operating system network stack thus emulating their reception from an external source.
Now, let's suppose that I create a tun with IP 12.12.12.1. If on this machine I have two NICs, will I be able to communicate with this tun (on 12.12.12.1 IP) from an external machine(let's say 12.12.12.2) no matter what NIC device the second machine is connected to (let's say eth0 or eth1)?
With other words, are the tun and NICs independent one of each other, or you need to communicate with the tun through a specific NIC?
N.B. Links on topic are welcome!
If you set up a virtual network e.g. 12.12.12.0/24 that is reachable via your virtual interface and you send a packet to this network from your machine, the kernel module implementing tun/tap will send this packet from the kernel via a character device to your application. It is up to your application that what it does with this packet. It can be transmitted to some other application (e.g. VPN server). Your application can also feed packets back via this character device, and the OS network stack will see these packets as ingress network traffic.
If the machine acts as a router it can just use a tun/tap virtual interface as a regular one and forward traffic via it, but it is always the application handling the device that manages packets. Outgoing traffic via the virtual interface is always delivered to your application, and incoming traffic via the virtual interface always originates from your application.
Related
I played a bit with the official dpdk by setting up the environment and running some example applications. Then I found out about the UDPDK which combined the DPDK with the UDP stack.
I already have set up the environment for UDPDK as per documentation and then ran the sample app 'pktgen' (both in the local VM and on the public server). Now as far as I understand, this project's aim was to send pure UDP packets between connected devices.
I tried to send UDP packets from VM1(using DPRK) to VM2(normal) and tried to receive packets through a normal UDP receiver (java app) and succeeded, Also was able to send from one server(using DPDK) to another server (normal & both servers are connected to same switch as I could arping between them)
Edit :
My next target / main goal is to send/receive UDP packets from/to 1 public server (using DPDK) to another public server (normal & they are not connected, and no control over switch). Then I came to know about Open vSwitch and been told that this can be the way though I saw DPDK-OVS being used between VM's mainly. Is it really possible to send/receive UDP packets from/to remote public server using DPDK-OVS and if so then how?
Thanks in advance for any help.
For the question can one send UDP packets between 2 servers which are remotely connected (not connected directly or through the switch); the answer is yes, one can do the same without any external or 3rd party switching applciation
Reason:
packets traverse through the local network using Ethernet and VLAN
packets traverse through the remote network using MPLS, IP address or tunnel protocols.
So as long a valid packet with ethernet, vlan, IP, UDP is constructed sending it locally or remotely is possible.
How to do it:
Ensure the port used supports VF
create a VF instance and bind to DPDK
use DPDK API such as pktmbuf_alloc, mtod, eth, IP, udp to create the desired packet.
send a packet on VF interface using tx_buffer or tx_burst.
As long as the right MAC address, VLAN and|or MPLS is right external routing is taken care.
If packets are travelled through the tunnelling via NAT, ip-in-ip or GRE|Geneve, then we have 2 options
Prepare the NAT, tunnelling in DPDK and send over a physical interface
send the custom packet from the DPDK application using TAP PMD into the kernel, using network IP route tables the packets will be forwarded with appropriate tunnelling.
The above second approach takes care of neighbour discovery and tunnelling overhead.
hence the use of DPDK-OVS or OVS or any virtual switch does not solve the underlying issue.
DPDK-OVS provides DPDK vhostuser/vhostuserclient type port as virtual (virtio) device to VM. to VM, the virtio device in VM is just like any other normal network device, the UDP applications runs on VM does not care what underlying network devices the VM runs, UDP receives/sends packet through Linux network stack. you could run another userspace stack on VM and UDP applications runs on top of the userspace stack to bypass VM Linux stack.
Suppose I run Wireshark on my PC, and I'm connected to a router, how can Wireshark know about all the traffic from that router?
Isn't the router supposed to isolate each client and route only their own data to and from themselves? What actually happens behind the scenes?
Suppose I run Wireshark on my PC, and I'm connected to a router, how can Wireshark know about all the traffic from that router?
If you have a router that's connected to multiple LANs, then Wireshark, running on a machine connected to one of those LANs, can't know about all the traffic from the router unless the router has been configured to, for traffic that would otherwise not be routed to that LAN, send a copy of the packet on that LAN.
If you're talking about a LAN switch, so that everything plugged into the switch is on the same LAN, the situation is similar - the switch would have to be configured to send copies of traffic to the switch port into which the machine running Wireshark is plugged.
The ability to do that is a common feature in higher-end switches; a port can be configured to be a "mirror port". See the Wireshark Wiki page on Ethernet capture setup for details. I don't know whether any routers provide an equivalent of "port mirroring".
The isolation of packets to ports is the functionality of a switch.
A hub sends the packets to all ports.
But your router acts also as a switch. You can place a device in front of the router and sniff from there. This device needs to be a hub, a switch with a monitor port or a splitter.
Or you can use arp spoofing to manipulate the arp tables of the computers in the network. But that is mostly considered as an attack.
Cheers,
Chris
I am new to network programming and try to understand managing traffic via TUN/TAP interface.
Since I have almost nonexistent system programming skills, and feel confident on Java; I use OpenVPN tun/tap driver and ready made Java binding for it. It works on TAP mode.
As an example application I am trying to imitiate no encryption, no authentication client server VPN application.
I can catch Ethernet Frame packets, but for the routing part, I failed miserably. (I can modify route/arp tables.)
Do anybody know how OpenVPN send packets from client to server, and from server to target. Opening sockets from Java looks like an alternative; but I was hoping that modifying packets(change IPs and/or MAC addresses) and writing back to the virtual tap interface would be enough. Is it so?
Can I inject packets to send other locations, or by default received packet moves towards application layer?
-- Edit:
Scneario
Client Tap0 _____ Server Tap0 ______ Target
Eth0 Eth0
Target: Ping from client, move through tap interfaces, target see only server ip (anonymization)
What I achived so far.
Catch traffic at client tap0 interface.
I coulnt forward traffic at server Tap so to fasten things I used Java socket programming between client-server.
Now I read packets from socket at server, and try to OpenVPN Tap driver's write method to move forward but I am not sure where do I fail. I see packets with tcpdump at server tap0, but they do not pass to server eth0.
My most important question is if I modify packet(ip, mac address) and call write method, is it possible that packet moves forward. (Or does it move to application layer whatever you change??)
Any help would be appreciated.
1. Routing is a Layer 3 (IP) problem and handled by the OS. As for the Ethernet frames on Layer 2, you have multiple options. In any case, you'll have to parse the incoming packets' headers and extract the MAC address, and decide based on the MAC where to pass the packet: To a specific client, all clients (broadcasts) or the local tap interface.
Option 1: On each client, use a tun device, and let the server use a tap device. Assign pseudo MAC addresses to each client, respond accordingly to ARP requests from the server's OS and let the OS on the server take care of the rest. Applicationwise, you'll only have to forward all incoming packets to the tap device and all outgoing packets to the client to which you assigned this MAC.
Option 2: Let the clients choose their own MAC address and forward ARP-requests through the network. The server application has to decide for incoming packets from a client whether to forward the packet to a client, or send it to the local tap device if the address matches the local device's MAC.
In both cases, clients pass all packets from their local tun/tap device to the server and vice versa.
2. You can do almost anything. A packet is only "received" when you decide to write it to the tap device, and you can of course temper with any packets, or inject new ones, ...
As a final comment, I've found that toying with tun devices is conceptually simpler, because they work on Layer 3. You'll have to open a tun device on the server for each client, but within your application you'll have to do nothing but to forward anything coming from the device to the single client, and vice versa.
Running on a Linux system, getting UDP packets from another computer address to let's say 192.168.0.2 from another address let's say 192.168.166.66, I can see the UDP packets coming in with tcpdump. However, if I use netcat I don't actually receive the packets.
If I create an interface on 192.168.166.XXX network, then netcat is able to receive the packets no problem.
What basic networking concept am I missing? Why do I need to have an interface on the network of the sending IP when I can see with tcpdump that they are being delivered correctly?
tcpdump per default puts the interface into promiscious mode, which lets you see all the packets arriving at your network interface. But, your operating system only processes packets destined for the local system, e.g. either having the local or a broadcast address as destination.
The final solution to this problem was to disable Reverse Path Forwarding (RPF) on the interface. There are security implications here, but after careful review this was the correct path forward in this particular case.
RPF was turned off by modifying /etc/sysctl.conf:
net.ipv4.conf.eth0.rp_filter=0
Some more information on RPF:
Wikipedia - Reverse path forwarding
Linux kernel rp_filter settings
we have little network devices which are shipped with IP address 0.0.0.1 to ensure that they never collide with any other device in their new environment (thus none of the 10.x.x.x, 172.16.x.x or 192.168.x.x ranges) until configuration. DHCP is no solution since there might be no DHCP server in the field.
The devices would listen to UDP broadcasts and answer with broadcasts until they are given their new IP address this way.
This worked fine with Windows XP - but sucks with Windows 7: the config program does not receive the answer packets from the devices which still have 0.0.0.1. Wireshark sees the packets, then they are dumped by the system.
Question: Is there any reason (RFC?) that actually prohibits using this address in a local environment? Or is it just MS that was overcautious? Where can I read why they treat this address "invalid"? Which ranges are really "invalid" now, too?
Any idea of a workaround on the PC side (Win 7)?
I know that it is not recommended to use 0.xxx addresses for work places, but for this very reason - having a not-used address - it works perfectly.
Edit: there is a device out there called "Netburner" which might have faced the similar issue, according to their forum. See: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Does - by coincidence - anybody know some background information?
It sounds as if your configuration application is listening for broadcast packets on all network interfaces and expecting to receive packets from foreign subnets.
That should not work - the OS should only pass-on broadcast packets from the subnets each network interface is on, not from all subnets on the same physical (e.g. Ethernet) segment. I am reasonably certain that doing otherwise is broken behaviour WRT the IP protocol.
The are two ways to deal with this:
Make sure that your network interface has an IP address in the target subnet. You can have more than one IP addresses for each network card, so that should not interfere with normal network operations.
Configure or modify you application to use raw sockets, like Wireshark. Keep in mind, however, that this overrides all normal checks and balances and should be avoided, since it can cause behaviour that is almost impossible to diagnose - which is why it is frowned upon by meny network administrators.
Can you you add new routing table entries to Windows machines easily? Windows has to know which interface to use when routing a broadcast packet to the 0.0.0.x network.
The Unix machines I'm familiar with have a routing table that maps network/netmask entries to either gateways or interfaces (if the network is a local network). The local network (192.168.0.0/16 for my home network) gets sent to interface eth0. Everything else 0.0.0.0/0 gets sent to a specific gateway machine 192.168.0.1.
If my machine sent a UDP broadcast message to network 0.0.0.0/24 (in other words, UDP broadcast sent to 0.0.0.255, then my machine would forward the packet to the gateway machine (which it can look up via arp). The switches in the middle wouldn't propagate the packet to other network devices, because the MAC address is set.
If my machine had another routing entry for 0.0.0.0/24 to the local interface, then my machine would send the packet on the wire using an ethernet broadcast group, and the switches would forward the packet to all connections. (Yay! Just like hubs in the 90s! :)
So I figure you need to add a routing entry for 0.0.0.0/24 to your client machines, so that they can properly address the broadcast packet.