Bind socketu na konkrétní síťovou kartu v C

[M_D]

Jan Novotný: A jak máš ty IP k těm síťovkám přiřazené? Uvádíš tři interfejsy a tři IP 192.168.1.51, 192.168.1.52, 192.168.1.53 a potřebu komunikovat přes třetí s iface name enp0s8. Bindneš v kódu k socketu daný iface enp0s8 a client IP 192.168.1.51. Nepatří k té třetí síťovce správně ta IP 192.168.1.53?

jjrsk: Ono ne vždy to standardní dělá co chci, občas se nějaká vylomenina hodí. :-) Třeba něčím podobným, v kombinaci s multicastem, tak obcházím nutnost mít switche s HSR (které stojí nechutný peníz a navíc mají obvykle moc málo portů) a stačí mi k tomu obyč switche s MSTP a 2 VLANy a mám také bezeztrátový přenos a "zero-time recovery" při selhání jednoho switche/propoje.

[Reklama]

[František Ryšánek]

Jan Novotný: A jak máš ty IP k těm síťovkám přiřazené? Uvádíš tři interfejsy a tři IP 192.168.1.51, 192.168.1.52, 192.168.1.53 a potřebu komunikovat přes třetí s iface name enp0s8. Bindneš v kódu k socketu daný iface enp0s8 a client IP 192.168.1.51. Nepatří k té třetí síťovce správně ta IP 192.168.1.53?

Musel přijít ten co dává pozor... :-D

[M_D]

Já chválím za ten rp_filter - bez jeho vypnutí to nefunguje, pokud mám víc síťovek ve stejném IP segmentu. :-)
Jsem to zkusil pustit. Funguje to a data dojdou zpět do recvfrom(). Pokud binduji konkrétní iface a client IP, tak by měla být shoda toho IP a iface, datagram musí přijít tím bindnutým ifacem a navíc musí být vypnutý rp_filter pro daný iface (zkrátka musí souhlasit na příchozím daná IP a iface). Pokud jako odchozí IP dám jinou, než odpovídá na vynucený iface, tak ono to odejde přes bindnutý iface se zadanou IP, ale vlivem ARP a forward tabulky ve switchi se odpověď vrátí často jiným ifacem a je smůla (pokud se vrátí tím předepsaným, tak se data také doručí do recvfrom()). Je to celkem striktní v případě unicast provozu.

[M_D]

...by mě zajímalo, co by se stalo, kdybych spustil nějaký proces přímo, bez "ip netns exec $NAMESPACE", a pak bindoval sockety na rozhraní, již přiřazená popsaným způsobem do izolovaných namespaces...

V takovém připadě se tomu procesu to nepovede, protože daný iface/IP v jiném namespace nevidí. Zkrátka to dopadne No such device/Cannot assign requested address.
Proces, pokud má práva (CAP_SYS_ADMIN), tak si může přepnout namespace pomocí setns(). Přesněji, je to per vlákno, takže jde pak použít vícevláknová aplikace, kde každé vlákno binduje/používá interfejsy v jiném namespace.
Takže toto je možná i čistější řešení pro tazatele, kdy si tu třetí síťovku hodí do jiného namespace a spustí tu apku nad tím, pokud by potřeboval komunikvoat přes víc sítí, tak víc těch vláken v různých net namespaces...

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

takže server má tři síťové adresy?
Mělo by to jít, když místo IP adresy  originu uvedete síťové rozhraní originu , pak se použije daná adresa.
Ale nevím , zda to půjde v kódu. By mě zajímalo, jak to dělá curl.
Nicméně, pokud by to nešlo přepsat,  a opravdu bys musel použít IP adresy jako specifikátor originu, tak abys docílil výběru rozhraní, bys musel použít ip virtuální routovací tabulky ( *** ), přičemže v každé bude default routa přes jiné síťové rozraní ... default via. .192.168.1.5x dev ethY   + routa pro  místní sít, pochopil jsem, že vše je v jednom subnetu)a policy routing  (ip rule add from 192.168.1.5x lookup tabulkarozhrani3)

ale mám pocit, že to je rovnák na něco ohnutého



*** víte o způsobu jak přes příkaz ip * přidat virt. rout. tabulku jinak než echo mojetable >> /etc/iproute2/rt_tables?

(sice píšete že server je svatá kráva, že se nemůže sahat na konfiguraci)

[Reklama]