Ruch GRE nie jest przekazywany do lokalnej podsieci


0

Mam dwie maszyny Debiana w różnych lokalizacjach i chcę umożliwić routing między dwiema wewnętrznymi podsieciami przez GRE.

Moje ogólne routing już działa, co oznacza, że ​​jakakolwiek wewnętrzna maszyna kieruje ruch w kierunku dwóch maszyn, które są połączone przez GRE, a także ruch jest wysyłany przez tunel, ale po odebraniu tego ruchu nie jest już przekazywany do lokalnej podsieci.

Moja konfiguracja na tych dwóch komputerach (nie używających rzeczywistych adresów IP):

Host A (172.19.0.1):

ip tunnel add tun0 mode gre remote 172.20.0.1 local 172.19.0.1
ip addr add 10.10.10.1/24 dev tun0
ip link set tun0 up

Host B (172.20.0.1):

ip tunnel add tun0 mode gre remote 172.19.0.1 local 172.20.0.1
ip addr add 10.10.10.2/24 dev tun0
ip link set tun0 up
echo 1 > /proc/sys/net/ipv4/ip_forward

Pingowanie obu maszyn na adresach IP interfejsu tunelu (10.10.10.1 i 10.10.10.2) działa bezbłędnie, ale kiedy próbuję pingować wewnętrzny adres IP przez tunel, np. Działając ping 10.100.77.8 -I tun0na hoście AI, nie otrzymuję odpowiedzi. tcpdumppokazuje, że nie ma nawet jednego wygenerowanego, co wskazuje, że pakiet nigdy nie trafia w interfejs po rozpakowaniu przez GRE.

root@hostb:~# tcpdump -i any host 172.19.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:36:10.983403 IP 10.10.10.1 > 172.20.0.1: GREv0, length 88: IP 10.10.10.1 > 10.100.77.8: ICMP echo request, id 20422, seq 8, length 64
10:36:10.983419 IP 10.10.10.1 > 10.100.77.8: ICMP echo request, id 20422, seq 8, length 64
10:36:11.991415 IP 10.10.10.1 > 172.20.0.1: GREv0, length 88: IP 10.10.10.1 > 10.100.77.8: ICMP echo request, id 20422, seq 9, length 64
10:36:11.991427 IP 10.10.10.1 > 10.100.77.8: ICMP echo request, id 20422, seq 9, length 64

Nie widzę pakietu ICMP przychodzącego na maszynie docelowej 10.100.77.8. W iptables nie ma żadnych reguł, podczas gdy domyślna akcja jest zawsze ACCEPT.

Odpowiedzi:


0

Problem rozwiązany. rp_filterzostało włączone dla interfejsów tunelowych

$ cat /proc/sys/net/ipv4/conf/all/rp_filter
1
$ cat /proc/sys/net/ipv4/conf/tun0/rp_filter
1

Zmiana obu w celu 0rozwiązania problemu.


0

Wydaje się, że coś jest nie tak z wyborem adresu źródłowego, ponieważ masz wewnętrzny adres tunelu w zewnętrznym nagłówku pakietów GRE. Adres źródłowy zewnętrznego nagłówka powinien być 172.19.0.1, a nie 10.10.10.1.

10:36:10.983403 IP10.10.10.1> 172.20.0.1: GREv0, length 88:\ IP 10.10.10.1 > 10.100.77.8: ICMP echo request, id 20422, seq 8, length 64

Sprawdź wyjście ip route get 10.100.77.8na gospodarzem . Sprawdź również wyjście ip route get 10.100.77.8 from 10.10.10.1 iif tun0na gospodarza B . Jeśli widzisz coś takiego invalid cross-device link, wyłącz rp_filter.

Pokaż także wynik ip -4 r lspolecenia „ ” z obu hostów.


Pakiet został wygenerowany na maszynie obsługującej GRE, więc wybrał go jako źródłowy adres IP. Nie było problemu w tym przypadku. Doszedłem do wniosku, że domyślnie rp_filter jest aktywowany na komputerach dla nowych interfejsów. Dezaktywacja tego rozwiązała problem. Skomponuje ostateczną odpowiedź na to pytanie.
Dero

To nie jest normalna sytuacja. Wpadnięcie rp_filterto tylko efekt uboczny innego problemu. Masz niepełną konfigurację routingu. Sprawdź wydajność iptables-save. Spowoduje wyświetlenie pełnego zestawu reguł zapory.
Anton Daniłow

Jak powiedziano, w iptables nie ma żadnych konfiguracji. Ale proszę bardzo:*filter:INPUT ACCEPT [0:0]:FORWARD ACCEPT [0:0]:OUTPUT ACCEPT [0:0]COMMIT
Dero

Nie mogę wyjaśnić niedopasowania adresu źródłowego, ale wpłynie to na twoją konfigurację w przyszłości.
Anton Daniłow
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.