Kopie zapasowe (za pośrednictwem Baculi) jednego z moich serwerów („A”) połączonych przez IPSec (Strongswan na testach Debiana) z demonem pamięci („B”) nie kończą 95% razy. Najwyraźniej dzieje się tak:
- Bacula otwiera połączenie TCP z IP VPN demona pamięci. (A → B)
- Ponieważ ustawienie jądra
net.ipv4.ip_no_pmtu_disc=0
jest ustawione domyślnie, bit Nie fragmentuj adresu IP jest ustawiony w pakiecie zwykłego tekstu. - Podczas kierowania pakietu do tunelu IPSec bit DF ładunku jest kopiowany do nagłówka IP pakietu ESP.
- Po pewnym czasie (często około 20 minut) i wysłaniu do kilku gigabajtów danych wysyłany jest pakiet nieco większy niż pakiety ESP przedtem. (A → B)
- Ponieważ interfejs demona pamięci ma niższą MTU niż hosta wysyłającego, router po drodze wysyła do hosta błąd ICMP typu 3, kod 4 (Wymagana fragmentacja i nie ustawiono fragmentu). (niektóre routery → A)
- Połączenie zatrzymuje się, z jakiegoś powodu host A zalewa ~ 100 pustych duplikatów ACK do B (w ciągu ~ 20 ms).
(Pakiety ICMP docierają do hosta A i nie istnieją żadne reguły iptables, które blokowałyby ICMP.)
Możliwe powody, dla których tak się dzieje, o których mogę myśleć:
- Błąd jądra (Debian 3.13.7-1)
- Implementacja IPSec w systemie Linux celowo ignoruje komunikat PMTU jako środek bezpieczeństwa, ponieważ nie jest chroniony i miałby wpływ na istniejące SA. (wydaje się być prawidłowym zachowaniem zgodnie z RFC 4301 8.2.1 )
- Ma coś wspólnego z procesem starzenia się PMTU ( RFC 4301 8.2.2 )
Jaki jest najlepszy sposób, aby to naprawić bez wyłączania globalnego wykrywania PMTU lub obniżania MTU interfejsu? Może wyczyściłem bit DF jakoś to, co robi FreeBSD z ipsec.dfbit = 0 ?
net.ipv4.ip_no_pmtu_disc=1
naprawia ten konkretny problem. Jednak moim zdaniem nie jest to idealne rozwiązanie.