OpenVPN: Jak ograniczyć problemy MTU ścieżki dla poszczególnych klientów?

Mamy dziesiątki urządzeń wbudowanych zainstalowanych u klientów, wszyscy dzwonią do domu do naszej usługi OpenVPN. To ogólnie działa dobrze, ale kilku naszych klientów ma poważne problemy z MTU ścieżki. Nasz wpływ na klientów w zakresie naprawy ich sieci jest ograniczony, dlatego potrzebujemy OpenVPN, aby sobie z tym poradzić. Krótko mówiąc, moje pytanie brzmi:

Jak mogę ograniczyć MTU niskich ścieżek niektórych klientów dla poszczególnych klientów, to znaczy bez używania ustawień globalnych uwzględniających najgorszy przypadek dla wszystkich klientów

Zauważ, że nasz najgorszy przypadek jest całkiem zły: ścieżka MTU 576, usuwa wszystkie fragmenty, nie fragmentuje się sama, nie honoruje bitów DF. Widzisz, dlaczego wolałbym nie rozwiązywać tego problemu na całym świecie.

Strona OpenVPN oferuje szereg opcji związanych z MTU, w szczególności --link-mtu, --tun-mtu, --fragment and --mssfix. Ale to też mówi

--link-mtu [...] Najlepiej nie ustawiać tego parametru, chyba że wiesz, co robisz.

--tun-mtu [...] Najlepiej jest użyć opcji --fragment i / lub --mssfix, aby poradzić sobie z problemami z rozmiarami MTU.

Więc zacząłem eksperymentować z --fragmenti --mssfixale wkrótce musiał zdać sobie sprawę, że przynajmniej dawny należy ustawić nie tylko po stronie klienta, ale także po stronie serwera . Potem przejrzałem konfigurację po stronie serwera dla klienta za pośrednictwem, --client-config-dirale mówi

W kontekście specyficznym dla klienta dozwolone są następujące opcje: --push, --push-reset, --iroute, --ifconfig-push i --config.

Brak wzmianki o opcjach MTU!

Oto moje bardziej szczegółowe pytania:

Dlaczego dokładnie link-mtui tun-mtuodradzamy? Jakie są potencjalne problemy z tymi opcjami? Zauważ, że czuję się całkiem dobrze z niskim poziomem mungowania nagłówka IP.
Które z opcji link-mtu tun-mtu fragment mssfixmuszą być dublowane po stronie serwera, aby działały?
W której z opcji link-mtu tun-mtu fragment mssfixmożna użyć client-config-dir?
W przypadku, gdy wszystkie cztery opcje muszą być dublowane po stronie serwera i nie można ich użyć wewnątrz client-config-dir: Czy istnieją jakieś alternatywy dla walki z niską ścieżką MTU na klienta?

Uwagi:

Części moich pytań już został poproszony 5 lat temu tutaj , Ale naprawdę nie odpowiedziano wtedy, dlatego ośmielam się je powielać.
Serwer OpenVPN ma obecnie wersję 2.2.1 na Ubuntu 12.04. Przygotowujemy aktualizację do wersji 2.3.2 na Ubuntu 14.04
Klienci OpenVPN to 2.2.1 na Debianie 7.6
Z przyjemnością określam ręcznie MTU ścieżki klienta
Obecnie nie możemy przetestować dużo po stronie serwera. Ale budujemy kompletne oddzielne łóżko testowe, które powinno być wkrótce gotowe.

Jestem wdzięczny za wszelkie pomocne porady.

ip openvpn mtu ip-fragmentation

— Nils Toedtmann
źródło

576? Drogi Boże. Nie widziałem MTU tak niskiego od czasów dialupu. Czy to przechodzi przez starożytne łącze szeregowe?

— Michael Hampton

Czy możesz uruchomić dwa serwery OpenVPN? Być może możesz uruchomić oba serwery na tym samym publicznym adresie IP i użyć przekierowania portów (lub zasady routingu), aby skierować klientów do innego serwera OpenVPN w zależności od tego, czy są oni w znanej problematycznej sieci, czy nie (zgodnie z listą klientów Adresy IP).

— kasperd

@MichaelHampton Też się zastanawiałem. To> 600kbit / si RTT ~ 30ms, nie wygląda mi to na starodawny serial. Biorąc pod uwagę, że mają inne głupie ustawienia (np. Nie reagują na DF z „potrzebną fragmentacją”), myślę, że to tylko kolejna. Powiedzieliśmy im, ale jeszcze nie otrzymaliśmy odpowiedzi.

— Nils Toedtmann

@kasperd ciekawy pomysł. Mogę uruchomić wiele instancji serwera OpenVPN. Musiałby mieć może 3 lub 4, dla różnych zakresów MTU. NAT po stronie serwera nie działa (nie mogę przewidzieć dynamicznych adresów IP klienta publicznego), ale i tak musiałbym zmienić konfigurację klienta dla ustawień MTU (prawda?), Więc po prostu skonfigurowałbym inny port prosto do klienta. - Ale to byłby koszmar serwisowy, którego wolałbym unikać!

— Nils Toedtmann

@NilsToedtmann Jakie kryteria zastosowałbyś do wykrycia, których klientów dotyczy? Innym podejściem może być uruchomienie skryptu na serwerze po połączeniu klienta. Skrypt może próbować wysłać polecenie ping do adresu IP klienta przy różnych rozmiarach pakietów, aby dowiedzieć się, które działają, a które nie. Następnie może wstawić iptablesreguły, aby zmniejszyć MSS na wszystkich pakietach SYN do lub z tego adresu IP klienta.

— kasperd

Rozwiązałem problem po stronie klienta, dodając opcję mssfix 1300do pliku konfiguracyjnego.

Ze strony man openvpn:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

Oryginalny pomysł na moje rozwiązanie przyszedł od personalvpn.org

— Oz123
źródło

Czy mssfixmożna ustawić tylko po stronie klienta? Cóż, to przynajmniej coś. Nie pomaga to jednak w pakietach UDP (dlatego interesowały mnie inne opcje, ale przynajmniej zalecane fragmentmuszą być ustawione również po stronie serwera)

— Nils Toedtmann

mssfix można dodać zarówno na serwerze, jak i na kliencie. Jednak mniejsza wartość zostanie wykorzystana w negocjacjach

— Ahmed,

Biorąc pod uwagę brak odpowiedzi, publikuję teraz rozwiązanie, które nie jest zbyt eleganckie, ale proste: Uruchom inną instancję OpenVPN na TCP dla „złych klientów”

proto tcp

i obniż TCP MSS na kliencie, np

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Zaletą tego rozwiązania jest to, że każdy klient może ustawić swój indywidualny MSS.

Jest to wprawdzie TCP-over-TCP, ale powinno to działać wystarczająco dobrze w wielu scenariuszach .

Pamiętaj, że nadal jestem bardzo zainteresowanym rozwiązaniami, które nie wymagają proto tcp, i zaznaczę je jako prawidłową odpowiedź, jeśli mniej więcej spełniają moje określone wymagania.

— Nils Toedtmann
źródło