Połączenie TCP przez IPSec (Linux / Strongswan) zatrzymuje się po przekroczeniu PMTU


5

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:

  1. Bacula otwiera połączenie TCP z IP VPN demona pamięci. (A → B)
  2. Ponieważ ustawienie jądra net.ipv4.ip_no_pmtu_disc=0jest ustawione domyślnie, bit Nie fragmentuj adresu IP jest ustawiony w pakiecie zwykłego tekstu.
  3. Podczas kierowania pakietu do tunelu IPSec bit DF ładunku jest kopiowany do nagłówka IP pakietu ESP.
  4. 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)
  5. 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)
  6. 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 ?


1
Udało mi się potwierdzić, że wyłączenie wykrywania PMTU przez ustawienie net.ipv4.ip_no_pmtu_disc=1naprawia ten konkretny problem. Jednak moim zdaniem nie jest to idealne rozwiązanie.
al.

Odpowiedzi:


2

Możesz spróbować utworzyć regułę w iptablescelu ustawienia niższej wartości TCP MSS dla ruchu przeznaczonego dla VPN. Ale bez przechwytywania pakietów trudno zgadnąć, co się dzieje.


Ponieważ ESP jest wysyłany przez UDP, nie mogę poprawiać MSS. Oczywiście mógłbym zastosować ograniczenia MSS do niezaszyfrowanego połączenia TCP, ale byłoby to nie mniej obejście niż obniżenie MTU interfejsu lub całkowite wyłączenie wykrywania PMTU.
al.

Najprawdopodobniej wykrywanie PMTU nie działa z powodu brakujących odpowiedzi ICMP (wymagana defragmentacja) z serwera IPsec. Powyższe porady dotyczą ograniczenia MSS dla połączeń przez IPsec, a nie pod tunelem ESP.
stymulacja

Błędy ICMP docierają do hosta IPSec w porządku. Ponieważ najmniejsza MTU ze wszystkich chmielu nie jest znana, należałoby odgadnąć pewien limit MSS.
al.

Możesz uruchomić, mturouteaby ustalić najmniejszą MTU.
Ben

0

Jeśli wykrycie PMTU w scenariuszu VPN kończy się niepowodzeniem, jest to zazwyczaj problem z publicznymi adresami IP bram lub routerów pomiędzy lub filtrowanymi komunikatami ICMP. Zaciskanie MSS to tylko brzydkie obejście.

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.