Forum Debian Users Gang

Hmm, to zostawmy na tę trasę wielościeżkową. No to teraz pytanie jest, jak to zrobić w oparciu o trasy routingu? Patrzyłem jak to mwan3 na OpenWRT zrobił i wychodzi na to, że powinienem dodać do pliku /etc/iproute2/rt_tables dwie tablice. Dodałem:

10 home
20 lte

Skonfigurowałem sobie dwa interfejsy sieciowe bond0 i wwan0 przez /etc/network/interfaces i podniosłem je oba. Tak wygląda tablica routingu main:

# ip route show table main
default via 192.168.1.1 dev bond0  metric 10
default via 10.140.17.21 dev wwan0  metric 100
10.140.17.20/30 dev wwan0  proto kernel  scope link  src 10.140.17.22
192.168.1.0/24 dev bond0  proto kernel  scope link  src 192.168.1.150
192.168.10.0/24 dev br-lxc  proto kernel  scope link  src 192.168.10.100

Te bramki domyślne, co tutaj są, dodałem do osobnych tablic routingu. Ta od bond0 jest w home, a ta od wwan0 w lte:

# ip route show table home
default via 192.168.1.1 dev bond0

# ip route show table lte
default via 10.140.17.21 dev wwan0

Czyli w tym momencie wystarczy dodać odpowiednie reguły dla routingu i powinno działać? Patrząc na to co mwan3 uzupełnił na OpenWRT, dodałem parę reguł i wyszło coś takiego:

# ip rule show
0:      from all lookup local
1001:   from all iif bond0 lookup main
1002:   from all iif wwan0 lookup main
2002:   from all fwmark 0x2/0xff lookup lte
32766:  from all lookup main
32767:  from all lookup default

Czyli zgodnie z tym powyższym, wszytko co jest oznaczane markiem 0x2/0xff powinno powędrować do tablicy lte, a tam, że jest wpis od bramy domyślnej, to pakiet powinien powędrować przez interfejs wwan0. Pakiety są oznaczane w łańcuchu INPUT tablicy mangle w iptables, czyli przed decyzją o routingu. No ale jest problem, bo to nie działa. xD Połączenia oznaczone mark=2 zwyczajnie nie są realizowane. Tzn. pakiety są wysyłane ale najwyraźniej nie potrafią wrócić:

# cat /proc/net/nf_conntrack | grep mark=2
ipv4     2 tcp      6 37 SYN_SENT src=192.168.1.150 dst=185.52.170.19 sport=39142 dport=80 [UNREPLIED] src=185.52.170.19 dst=192.168.1.150 sport=80 dport=39142 mark=2 zone=0 use=2
ipv4     2 tcp      6 116 SYN_SENT src=192.168.1.150 dst=185.52.170.8 sport=56180 dport=80 [UNREPLIED] src=185.52.170.8 dst=192.168.1.150 sport=80 dport=56180 mark=2 zone=0 use=2
ipv4     2 tcp      6 104 SYN_SENT src=192.168.1.150 dst=52.25.175.6 sport=37906 dport=443 [UNREPLIED] src=52.25.175.6 dst=192.168.1.150 sport=443 dport=37906 mark=2 zone=0 use=2

Ciągle mają ten SYN_SENT. W wiresharku mam mnóstwo retransmisji. Czyli coś gdzieś źle jest ustawione albo o czymś zapomniałem, tylko o czym? xD Dlaczego w tych oznaczonych połączeniach jest adres src=192.168.1.150 , on przecie jest powiązany z interfejsem bond0? Ja powinienem tym pakietom jakoś to źródło przepisać w oparciu o coś? xD

EDIT:

Niby dałem:

# iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o wwan0 -j MASQUERADE
-A POSTROUTING -o bond0 -j MASQUERADE

W tablicy conntracka są wpisy typu:

ipv4     2 tcp      6 431993 ESTABLISHED src=192.168.1.150 dst=5.39.94.136 sport=45186 dport=80 src=5.39.94.136 dst=10.140.17.22 sport=80 dport=45186 [ASSURED] mark=2 zone=0 use=2

I tera działa. To tak ma być?

Ostatnio edytowany przez morfik (2016-05-18 17:32:32)

Warte odnotowania: xD

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

No to w końcu ustaliłem WTF.

IPv4: Hash-based multipath routing. When the routing cache was removed in 3.6, the IPv4 multipath algorithm changed from more or less being destination-based into being quasi-random per-packet scheduling. This increased the risk of out-of-order packets and made it impossible to use multipath together with anycast services. In this release, the multipath routing implementation is replaced with a flow-based load balancing based on a hash over the source and destination addresses merge commit

-- http://kernelnewbies.org/Linux_4.4[/quote]
Wychodzi na to, że z wypuszczeniem kernela 3.6 usunęli cache routingu, bo był "bee" (mniej niż 10% trafień i otwierał drogę do szeregu ataków). xD Na jego miejsce wprowadzili coś o nazwie "routing exception" ale to też było do dupy, bo było w stanie rozwalić połączenia przesyłając części pakietów przez inne interfejsy. xD Teraz od kernela 4.4 jest cache oparty na hashu, który spina adres źródłowy i docelowy. Każdy pakiet wysłany z określonego adresu IP na pewien adres docelowy zawsze będzie leciał tym samym interfejsem. Dlatego ta wielościeżkowa brama domyślna tak się zachowuje. Jeśli chce się robić bardziej zaawansowany load balancing (wciąż jednak oparty o połączenia, a nie o pakiety), to trzeba jechać na osobnych tablicach routingu, markować pakiety w stanie NEW w iptables i na podstawie tych marków rozdzielać ruch do osobnych interfejsów. No to z tym raczej już nie powinno być problemów, choć jeszcze nie wiem jak losowo markować pakiety różnymi markami ale to było chyba w mwan3. xD

Póki co przetestowałem przydzielając interfejsowi losowe adresy z mojej sieci i faktycznie w końcu zapytanie do serwera w necie poszło przez drugi interfejs.

Tutaj jest jeszcze więcej info: https://lwn.net/Articles/657431/

Ostatnio edytowany przez morfik (2016-05-20 19:29:04)