Do you have the capture file from your last dump? I'm super interested in seeing it so I can compare to mine.
If you are refering to my complaint that I am receiving traffic not addressed to me it is as easy as taking the tcpdump line and invert the direction of the capture:
tcpdump -Q in
-n -e not ether host <your first MAC> and not ether host <your second MAC> and not ether host <your other MAC>
This will reveal traffic you receive not addressed to your MACs. It is correct to see traffic not addressed to your specific IPs but inside the shared addressing space of your subnet. As an example if you IP is 192.168.1.5/27 traffic to 192.168.1.20 that is is the same subnet as you (in fact all that is between 192.168.1.1 and 192.168.1.30) is theoretically valid. But you should never, ever, see trafic to 192.168.2.x or any other else. Of course this is if routing is well configured. But I guess that in your capture you will see lots of packets sent to an IP address that is outside your scope. I am very interested too in knowing if that happens to you too. I have other servers at Hetzner and they also get this irregular traffic though not so intense. In this short capture of one other servers you can see:
1.- Wrong? traffic even inside their vSwitch (my server is using one of their virtual switches to connect with other servers internally. That 33:33:ff:* does not exist in that server though the IPv6 addresses are correct)
10:19:18.735110 84:c1:c1:76:af:b0 > 33:33:ff:00:00:02, ethertype 802.1Q (0x8100), length 90: vlan 4000, p 0, ethertype IPv6, fe80::86c1:c100:76:aff0 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2a01:xxx:xxx:xxx::2, length 32
10:19:18.735274 84:c1:c1:76:af:b0 > 33:33:ff:b2:13:b8, ethertype 802.1Q (0x8100), length 90: vlan 4000, p 0, ethertype IPv6, fe80::86c1:c100:76:aff0 > ff02::1:ffb2:13b8: ICMP6, neighbor solicitation, who has fe80::xxx:xxx:xxx:13b8, length 32
2.- Valid traffic, not addressed to any of my servers but inside the network addressing scope (I am node 211)
10:19:18.870997 84:c1:c1:76:a9:50 > 00:50:56:00:76:cd, ethertype IPv4 (0x0800), length 66: 18.104.22.168.50526 > 176.xx.xx.210.445: Flags , seq 2037627499, win 8192, options [mss 1452,nop,wscale 2,nop,nop,sackOK], length 0
10:19:19.176027 84:c1:c1:76:a9:50 > 08:60:6e:45:c2:65, ethertype IPv4 (0x0800), length 60: 22.214.171.124.21 > 176.xx.xx.213.21: Flags , seq 23592960, win 0, length 0
3.- Invalid traffic shot to anywhere else inside the Hetzner cyberspace
10:19:19.237437 84:c1:c1:76:a9:50 > 00:50:56:00:62:1d, ethertype IPv4 (0x0800), length 60: 126.96.36.199.60000 > 188.8.131.52.1722: Flags , seq 1770544271, win 1024, length 0
For the initial server I did not capture to a file but to the screen so I lost the captured lines as soon as I closed the session but it is much about the same: From time to time (all along the day yesterday) the vmbr switch (I think it is the only one that is able to generate that kind of traffic because none of the packet data -MACs, IPs- belongs to any of my hosts and if it was the host the one that generated it, at the very least, the source IP should be one of the right IPs) sent a reset packet back.
And I think this is malware because no one is so incompetent to, constantly, try to map a SMB drive (port 445) that does not own and not notice it is not the right IP. I think these are tries to find holes in servers exposed to internet and thus it is malware. And, should this be true, Hetzner is somehow collaborating to expand this malware beause they should be discarding that traffic in first place and blaming us of their misconfiguration.
But this is only my view and I may be wrong. Don't know if this was what you were expecting. If not do not hesitate to tell me and I'll try to grab the data you need.