Na ha már benne vagyok feldobom ezt a témát is, kíváncsi vagyok látott-e már valaki ilyet: Upgradeltem a szerverembe hálókártyát, jó áron sikerült hozzájutni egy Intel X710-DA4-hez, ami egy Intel X520-DA1 -et váltott. A host OS Win2022. Az új kártyán egyelőre csak egy port aktív, címe ugyanaz mint az előző kártyának. A kártyacserét leszámítva, és az új adapteren történő régi IP cím visszaállításon kívül semmiféle konfigurálás nem történt.
Legújabb Intel driver telepítve.
A host-on VMWare Workstation, benne fut jó néhány, de csak 4 aktívan használt Debian/Ubuntu VM. Amelyek bármelyikében ha kiadok egy ping parancsot mondjuk a google.com-ra akkor kérésenként 3 válasz érkezik. (A VM-ek network adapterei bridge-elve vannak host fizikai adapterével, tehát az X710 egyik portjával). Előtte ilyen probléma nem volt. Ha a host-on engedélyezem a "Routing and Remote Access" szolgáltatást, majd letiltom, a probléma megszűnik (De csak így sikerül megszüntetni, nem számít hogy előtte engedélyezve volt-e a szolgáltatás vagy sem) Igen ám, de ezzel gyakorlatilag megszűnik a routing is a host alatt. Így a host alá telepített OpenVPN szerver is használhatatlan lesz. (Az OpenVPN-hez egyébként nem kell az említett szolgáltatás, ha a registry-ben engedélyezve van az IPEnableRouter már működik, viszont a routing szolgáltatás engedélyezése és letiltása ezt kikapcsolja).
A probléma egyébként ismert:
https://thedatamachine.wordpress.com/2019/12/26/vmware-workstation-dup-packet-issue-resolved-sort-of/
https://communities.vmware.com/t5/VMware-Workstation-Pro/Duplicate-packets-with-ping-on-guest-O-Linux/td-p/2029093
Valós megoldást nem sikerült találni. Tehát vagy van routing a host alatt és jönnek a tripla ICMP packetek a VM-ekben, vagy nincs routing (így VPN sem) és a VM-ekben is minden jó. Próbáltam a nem használt adaptereket letiltani, winsock resetet, az adapter összes portját, semmivel nem sikerült változást előidézni.
- 117 megtekintés
Hozzászólások
Sajnos nem tudok megoldást a problémádra, egy hasonlóba viszont én is belefutottam. Egy kis tesztprogramot irtam, nagyon minimalista userspace swtich. AF_PACKET sockettel userspace-be copyzta a csomagot és kiküldte egy másik porton. Visszafelé ugyan ez, magyarán két port között bridgelt. Az AF_PACKET viszont nem dobja el a csomagot, így az folytatja útját a linux hálóstackjében is. Az az három válaszcsomagot láttam minden pingre:
1. Az AF_PACKET bridge amit átbridgelt, és erre kapott válaszcsomag
2. A linux stackben maga útját járó csomagra kapott válasz
3. A válasz csomag, ami szintén AF_PACKET-socketes interfészen jön be, nyilván megint el lesz küldve
Itt az lett nekem a megoldásom, hogy tc filterrel eldobtam az AF_PACKET után minden csomagot, konkrétan matchall action drop-al. Az AF_PACKET ugyanis per-device (van korábbi hook is, az XDP) és előbb van mint a tc, tehát nálam ez a megoldás teljesen jó volt.
- A hozzászóláshoz be kell jelentkezni