OpenVPN : 클라이언트별로 경로 MTU 문제를 완화하는 방법은 무엇입니까?

우리는 고객에게 수십 개의 임베디드 장치를 설치했으며 모두 OpenVPN 서비스를 이용합니다. 일반적으로 잘 작동하지만 일부 고객에게는 심각한 경로 MTU 문제가 있습니다. 고객의 네트워크 수정에 대한 영향은 제한적이므로이를 처리하려면 OpenVPN이 필요합니다. 요컨대 내 질문은 다음과 같습니다.

클라이언트 기반에서 일부 클라이언트의 낮은 경로 MTU를 완화하는 방법, 즉 모든 클라이언트에 대해 최악의 경우를 수용하는 전역 설정을 사용하지 않는 방법

경로 MTU 576은 모든 조각을 삭제하고 자체 조각화하지 않으며 DF 비트를 존중하지 않습니다. 왜이 문제를 전 세계적으로 해결하지 않으려는지 알 수 있습니다.

OpenVPN을 맨 페이지의 이벤트 MTU의 수는 특히, 옵션 관련 --link-mtu, --tun-mtu, --fragment and --mssfix. 그러나 그것은 또한 말한다

--link-mtu [...] 수행중인 작업을 모르면이 매개 변수를 설정하지 않는 것이 가장 좋습니다.

--tun-mtu [...] --fragment 및 / 또는 --mssfix 옵션을 사용하여 MTU 크기 문제를 처리하는 것이 가장 좋습니다.

내가 실험을 시작 그래서 --fragment하고 --mssfix곧하지만, 적어도 전자는 클라이언트 측,뿐만 아니라 설정해야 실현했다 또한 서버 쪽 . 나는 다음을 통해 서버 측 클라이언트 당 설정으로 보았다 --client-config-dir그러나 말한다

클라이언트 별 컨텍스트에서는 --push, --push-reset, --iroute, --ifconfig-push 및 --config 옵션이 유효합니다.

MTU 옵션에 대한 언급은 없습니다!

더 구체적인 질문은 다음과 같습니다.

왜 정확 link-mtu하고 tun-mtu낙담합니까? 이 옵션의 잠재적 문제점은 무엇입니까? 저수준 IP 헤더 뭉치에 상당히 익숙합니다.
link-mtu tun-mtu fragment mssfix작동하려면 서버 측에서 어떤 옵션 을 미러링해야합니까?
어떤 옵션을 link-mtu tun-mtu fragment mssfix사용할 수 client-config-dir있습니까?
4 가지 옵션을 모두 서버 측에 미러링해야하고 내부에서 사용할 수없는 경우 client-config-dir: 클라이언트 당 낮은 경로 MTU를 방지 할 수있는 대안이 있습니까?

노트:

내 질문의 일부는 이미 5 년 전에 여기 에 요청되었지만 실제로는 대답하지 않았으므로 복제해야합니다.
OpenVPN 서버는 현재 Ubuntu 12.04에서 2.2.1입니다. 우분투 14.04에서 2.3.2 로의 업그레이드를 준비하고 있습니다
OpenVPN 클라이언트는 데비안 7.6에서 2.2.1입니다
고객의 경로 MTU를 직접 결정하게되어 기쁩니다.
현재 많은 서버 측을 테스트 할 수 없습니다. 그러나 우리는 완전한 별도의 테스트 베드를 구축하고 있으며 곧 준비해야합니다.

도움이되는 조언에 감사드립니다.

ip openvpn mtu ip-fragmentation

— 닐스 토트 만
소스

576? 멍청 아 전화 접속 이후로 낮은 MTU를 보지 못했습니다. 그것은 고대의 직렬 링크를 통과합니까?

— Michael Hampton

두 개의 OpenVPN 서버를 실행할 수 있습니까? 동일한 공개 IP 주소로 두 서버를 모두 실행하고 포트 전달 (또는 라우팅 정책)을 사용하여 알려진 문제가있는 네트워크에 있는지 여부에 따라 클라이언트를 다른 OpenVPN 서버로 안내 할 수 있습니다 (클라이언트 목록에 의해 결정됨) IP 주소).

— kasperd

@MichaelHampton 나도 궁금했다. > 600kbit / s이고 RTT ~ 30ms이며, 고대 시리얼처럼 보이지 않습니다. 그들이 다른 어리석은 설정 (예 : '조각 필요'로 DF에 응답하지 않음)이 있다고 가정하면, 이것은 또 다른 것 같아요. 우리는 그들에게 말했지만 아직 듣지 못했습니다.

— Nils Toedtmann

@kasperd 재미있는 아이디어. 여러 OpenVPN 서버 인스턴스를 실행할 수 있습니다. 다른 MTU 범위에 대해 3 또는 4가 필요할 수 있습니다. 서버 측 클라이언트 당 NAT는 작동하지 않지만 (동적 공용 클라이언트 IP 주소를 예측할 수는 없지만) MTU 설정 (올바른?)에 대해 클라이언트 구성을 변경해야하므로 다른 포트를 똑바로 구성해야합니다 클라이언트로. -그러나 나는 피하는 것을 선호하는 유지 보수의 악몽 일 것입니다!

— Nils Toedtmann

@NilsToedtmann 어떤 클라이언트가 영향을 받는지 감지하기 위해 어떤 기준을 사용 하시겠습니까? 다른 방법은 클라이언트가 연결된 후 서버에서 스크립트를 실행하는 것입니다. 스크립트는 다양한 패킷 크기로 클라이언트 IP 주소를 핑하여 어떤 작업과 그렇지 않은 것을 알아낼 수 있습니다. 그런 다음 iptables모든 SYN 패킷의 MSS를 해당 클라이언트 IP 주소와주고받는 규칙을 삽입 할 수 있습니다 .

— kasperd

옵션 mssfix 1300을 구성 파일 에 추가하여 클라이언트 측의 문제를 해결했습니다 .

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.

내 솔루션에 대한 독창적 인 아이디어는 personalvpn.org 에서 나왔습니다.

— 오즈 123
소스

따라서 mssfix클라이언트 측만 설정할 수 있습니까? 글쎄, 그건 적어도 뭔가입니다. UDP 패킷에는 도움이되지 않습니다 (이로 인해 다른 옵션에 관심이 있었지만 최소한 권장 fragment되는 서버 쪽도 설정해야 함)

— Nils Toedtmann

mssfix는 클라이언트뿐만 아니라 서버에도 추가 할 수 있습니다. 그러나 더 작은 가치는 협상에 사용될 것입니다

— Ahmed

답변이 없기 때문에 매우 우아하지는 않지만 간단한 솔루션을 게시하고 있습니다. "나쁜 클라이언트"에 대해 TCP에서 다른 OpenVPN 인스턴스를 실행하십시오.

proto tcp

클라이언트에서 TCP MSS를 낮추십시오. 예 :

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

이 솔루션의 장점은 각 클라이언트가 개별 MSS를 설정할 수 있다는 것입니다.

이것은 TCP-over-TCP로 인정되지만 많은 시나리오에서 충분히 잘 수행되어야합니다 .

나는 여전히 필요하지 않은 매우 관심있는 솔루션이며 proto tcp, 내 요구 사항을 어느 정도 충족시키는 경우 유효한 답변으로 표시합니다.

— 닐스 토트 만
소스