Am găsit un workaround - folosesc ip secondary pe interfața eth0 în loc de dummy0. Se pare că curl --interface forțează pachetul să iasă prin interfața respectivă în loc să consulte tabela de routare...
Mai aștept totuși idei, că poate învăț ceva nou... 2014/1/13 Adrian Popa <[email protected]> > Ok, o captură de pachete îmi arată că adresa MAC destinație cu care pleacă > pachetele pe interfața dummy0 e aceeași cu adresa MAC sursă. Nu mi-e clar > dacă așa ar trebui să fie (să fie o particularitate a interfețelor dummy, > că oricum traficul ar trebui să fie routed mai departe), sau dacă e o parte > a problemei... > > > 2014/1/13 Adrian Popa <[email protected]> > >> Salutare. >> >> Încerc să configurez pe un server o clasă de test (publică, /30) pe o >> interfață dummy0 și să routez traficul către interfață prin server. Am >> câteva probe smokeping (curl) care trebuie să facă trafic cu sursă în >> /30-ul ăsta să văd cum se comportă niște resurse. >> >> Totul pare configurat ok, doar că nu reușesc să fac trafic cu curl cu >> interfața dummy0 ca sursă (adresele ip au fost mascate, pentru protecția >> lor). >> >> Ce e configurat până acum: >> >> [root@crowbar ~]# cat /etc/redhat-release >> CentOS release 6.4 (Final) >> [root@crowbar ~]# ip addr show dummy0 >> 6: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state >> UNKNOWN >> link/ether 76:2e:08:63:da:6a brd ff:ff:ff:ff:ff:ff >> inet 1.2.3.5/30 brd 1.2.3.7 scope global dummy0 >> inet6 fe80::742e:8ff:fe63:da6a/64 scope link >> valid_lft forever preferred_lft forever >> [root@crowbar ~]# ip route show >> default via 5.6.7.8 dev eth0 proto static >> 1.2.3.4/30 dev dummy0 proto kernel scope link src 1.2.3.5 >> 5.6.7.0/24 dev eth0 proto kernel scope link src 5.6.7.120 metric 1 >> >> [root@crowbar ~]# cat /proc/sys/net/ipv4/ip_forward >> 1 >> [root@crowbar ~]# cat /proc/sys/net/ipv4/conf/eth0/rp_filter >> 0 >> [root@crowbar ~]# cat /proc/sys/net/ipv4/conf/dummy0/rp_filter >> 0 >> >> iptables are permiturile necesare pe forward, dar am încercat și cu el >> dezactivat și e același lucru. >> >> >> Comanda pe care trebuie să o rulez e: >> curl --interface dummy0 www.google.com >> >> iar într-un strace se termină așa: >> ... >> setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "dummy0\0", 7) = 0 >> bind(3, {sa_family=AF_INET, sin_port=htons(0), >> sin_addr=inet_addr("1.2.3.5")}, 16) = 0 >> getsockname(3, {sa_family=AF_INET, sin_port=htons(45178), >> sin_addr=inet_addr("1.2.3.5")}, [16]) = 0 >> fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) >> fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 >> connect(3, {sa_family=AF_INET, sin_port=htons(80), >> sin_addr=inet_addr("173.194.44.49")}, 16) = -1 EINPROGRESS (Operation now >> in progress) >> poll([{fd=3, events=POLLOUT|POLLWRNORM}], 1, 49997^C <unfinished ...> >> [root@crowbar ~]# >> >> pe interfața dummy0 o captură tcpdump îmi arată că "pleacă" pachetele syn: >> >> 08:38:45.690031 IP 1.2.3.5.45178 > 173.194.44.49.http: Flags [S], seq >> 1063168827, win 14600, options [mss 1460,sackOK,TS val 2624613509 ecr >> 0,nop,wscale 7], length 0 >> >> în schimb, pachetele nu ies pe eth0. >> >> Nu m-am prins ce îmi scapă. De ce mai am nevoie ca pachetele să fie >> routate de mașina mea? >> >> Mulțumesc! >> > > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
