MTU 불일치가 홈 서버 연결 일부 문제를 일으키는 이유는 무엇인가요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Does MTU Mismatch Cause Partial Home Server Connectivity? - Zima Store Online

MTU 불일치는 작은 패킷은 경로를 통과하지만 큰 패킷은 통과하지 못해 홈 서버 연결이 부분적으로 실패하는 원인입니다. DNS 응답, TCP 핸드셰이크, 핑, 짧은 API 호출은 성공할 수 있어 경로가 정상인 것처럼 보입니다. 그러나 TLS, 웹 응답, 업로드 또는 파일 전송이 한 링크가 처리할 수 있는 IP 패킷보다 큰 패킷을 생성하면 연결이 멈춥니다.

올바른 경로는 그 크기 제한을 보고하여 송신자가 패킷 크기를 줄일 수 있게 합니다. 터널, 가상 브리지, 라우터 또는 ISP 링크에 더 작은 MTU가 있고 피드백이 송신자에게 도달하지 않거나, 서로 다른 계층이 실제 캡슐화된 경로를 반영하지 않는 크기를 광고할 때 부분 실패가 발생합니다. 결과는 도달 가능하지만 신뢰할 수 있는 데이터 전달이 불가능한 상태입니다.

간단한 답변: 패킷 크기는 연결성의 일부입니다.

MTU는 인터페이스가 한 번의 링크 계층 전송에서 보낼 수 있는 가장 큰 IP 패킷 크기입니다. 엔드포인트는 단지 홈 서버 이더넷 포트에 표시된 1500바이트 설정뿐 아니라 전체 경로에서 사용할 수 있는 가장 작은 값을 중요하게 생각합니다. VPN과 오버레이 헤더가 공간을 차지하므로 LAN에 맞는 패킷도 캡슐화 후에는 너무 클 수 있습니다.

실패가 부분적인 이유는 프로토콜이 작은 제어 패킷으로 시작하기 때문입니다. TCP 3방향 핸드셰이크가 완료되고 브라우저가 연결할 수 있지만, 어느 쪽도 전체 크기의 데이터 세그먼트를 보내기 전입니다. 너무 큰 패킷이 사라지는 동안 확인 응답과 작은 재전송은 통과하면 세션은 살아있는 것처럼 보이지만 거의 진행되지 않습니다.

MTU, MSS, 그리고 경로 MTU 발견은 관련 있지만 서로 다릅니다.

인터페이스 MTU는 한 인터페이스에서 보낼 수 있는 IP 패킷 크기를 제한합니다. TCP 최대 세그먼트 크기(MSS)는 각 세그먼트에서 엔드포인트가 원하는 TCP 페이로드 크기를 광고하며, IP와 TCP 헤더 공간을 남겨둡니다. MSS 클램핑은 라우터에서 광고된 페이로드 크기를 줄일 수 있지만, 이는 모든 UDP나 ICMP 패킷이 아닌 TCP 협상에 영향을 미칩니다.

경로 MTU 발견(Path MTU Discovery, PMTUD)은 송신자가 경로상에서 가장 작은 MTU를 알 수 있게 해줍니다. IPv4의 경우, RFC 1191은 Don’t Fragment 비트가 설정된 패킷을 전달할 수 없는 라우터가 ICMP 단편화 필요 피드백를 반환하는 과정을 정의합니다. 송신자는 이 값을 낮춰서 패킷을 재전송할 수 있습니다.

IPv6 라우터는 전송 패킷을 분할하지 않습니다. RFC 8201은 IPv6 노드가 ICMPv6 패킷 너무 큼 메시지를 사용하여 더 작은 경로 MTU를 학습하도록 규정합니다. 해당 제어 트래픽을 차단하는 것은 데이터 경로를 강화하는 것이 아니라 엔드포인트가 실제 제한에 적응하는 것을 방해합니다.

홈 서버 경로에서 더 큰 패킷이 버려지기 시작하는 지점

터널은 사용 가능한 페이로드를 줄입니다

WireGuard, IPsec, PPPoE, VLAN 및 기타 캡슐화는 원래 패킷 주위에 헤더를 추가합니다. 1500바이트 내부 패킷은 이러한 헤더가 있을 경우 1500바이트 외부 링크에 변경 없이 들어갈 수 없습니다. 터널 인터페이스는 일반적으로 더 낮은 MTU를 광고하지만 수동 재정의나 중간 장치가 엔드포인트에 낙관적인 값을 남길 수 있습니다.

불일치는 원격 접속에 영향을 미칠 수 있지만 로컬 서비스는 완벽하게 유지될 수 있습니다. Wi-Fi에 연결된 휴대폰은 일반 이더넷을 통해 서버에 접속하지만, 같은 휴대폰이 VPN을 사용할 때는 더 작은 터널 경로를 사용합니다. 라우팅, 인증 및 작은 요청은 여전히 작동하기 때문에 증상은 애플리케이션 또는 인증서 문제와 유사할 수 있습니다.

중첩된 경로는 문제를 복잡하게 만듭니다. 컨테이너 패킷은 가상 이더넷 쌍과 브리지를 통과하고, VM 어댑터에 진입한 후 VPN에 진입할 수 있습니다. 제한적인 MTU는 전체 경로에 속하지만, 각 가시적 인터페이스는 자신의 계층에 대해 그럴듯한 값을 보고할 수 있습니다.

ICMP 피드백이 필터링되거나 손실됨

제한 라우터가 과도한 크기의 패킷을 버리고 그 오류가 출발지에 도달하면 PMTUD가 복구할 수 있습니다. 방화벽이 모든 ICMP 또는 ICMPv6를 무차별적으로 폐기하면 발신자는 경로가 전달할 수 없는 크기를 계속 사용하게 됩니다. Cloudflare는 이러한 현대적 실패를 경로 MTU 블랙홀이라고 설명합니다: 큰 패킷이 조용히 손실되는 동안 애플리케이션은 대기 상태에 머뭅니다.

비대칭 라우팅은 방화벽이 메시지를 의도적으로 차단하지 않아도 동일한 결과를 초래할 수 있습니다. 데이터 패킷은 한 경로를 통해 전송되고 ICMP 오류는 다른 경로를 통해 전송될 수 있으며, 정책 라우팅, NAT 또는 공급자 필터가 반환 메시지가 원래 발신자와 연결되는 것을 방해할 수 있습니다. 따라서 패킷 캡처는 데이터 방향과 피드백 방향 모두를 검사해야 합니다.

반복되는 TCP 재전송은 단서일 뿐 증거는 아닙니다. 혼잡과 무선 손실도 재전송을 유발합니다. 실패가 반복 가능한 페이로드 크기 근처에서 시작되고 작은 프로브가 성공하며 인터페이스 MTU 또는 광고된 MSS를 줄이면 즉시 진행이 복구될 때 MTU 문제가 더 가능성이 높습니다

가상 네트워크가 잘못된 크기를 광고합니다

컨테이너 브리지와 VM 스위치는 하위 레이어보다 큰 MTU를 상속하거나 기본값으로 설정할 수 있습니다. 컨테이너는 가상 인터페이스에 유효한 패킷을 생성하지만, 호스트가 이를 VPN, 클라우드 오버레이 또는 PPPoE 업링크를 통해 전송하면 너무 커질 수 있습니다. 오프로드 기능 때문에 캡처가 실제 와이어 패킷보다 크게 보일 수 있으므로 캡처 위치가 중요합니다.

문서화된 Docker 사례는 이 문제와 정확히 일치합니다: 작은 LDAP 요청은 성공했지만 응답이 사라졌는데, VPN MTU는 1400인데 Docker는 1500을 사용했기 때문입니다. 호스트 네트워킹이 앱을 수정한 것이 아니라 가상 계층 불일치를 제거했기 때문에 문제가 해결된 것처럼 보였습니다.

거대한 TCP 세그먼트를 보여주는 단일 캡처만으로 와이어 동작을 추론하지 마세요. 일반적인 세그멘테이션 오프로드는 운영체제에 큰 버퍼를 제공하고 나중에 분할할 수 있습니다. 수신 측에서 캡처하고, 진단을 위해 오프로드를 일시적으로 비활성화하거나, 제어된 패킷 크기 테스트와 인터페이스 카운터를 연관 지어 불가능한 프레임 전송 여부를 판단하세요.

증상	부분적으로 작동할 수 있는 이유	유용한 다음 테스트
핑과 SSH는 연결되지만 HTTPS는 멈춤	제어 패킷은 맞지만 TLS 또는 응답 패킷은 맞지 않음	분할 없이 크기를 점차 늘려가며 테스트
LAN은 작동하지만 VPN은 실패	캡슐화가 원격 경로 MTU를 줄입니다	터널 MTU와 내부 패킷 크기 비교
다운로드는 실패하지만 작은 API 호출은 통과	서버에서 클라이언트로 가는 더 큰 패킷만 한계를 넘습니다	양방향 캡처 후 재전송 여부 확인
호스트는 작동하지만 컨테이너는 시간 초과 발생	가상 인터페이스가 하위 레이어보다 더 큰 MTU를 광고합니다	호스트, 브리지, 컨테이너 및 터널 설정 비교

업스트림 및 터널 설정이 실제 한계를 결정합니다

홈 서버가 항상 불일치를 만든 장소는 아닙니다. PPPoE, ISP 전환 메커니즘, 원격 접속 터널, 상위 라우터가 가장 좁은 링크를 도입할 수 있습니다. 물리 NIC만 변경하지 말고 클라이언트에서 서비스까지의 정확한 경로를 추적하고 모든 캡슐화 경계를 기록하세요.

PMTUD에 필요한 제어 메시지를 허용하세요. IPv4의 경우 관련 목적지 도달 불가 조각 필요 메시지, IPv6의 경우 Packet Too Big 메시지를 포함합니다. 모든 ICMP를 차단하지 말고 메시지 유형과 상태별로 엄격한 방화벽 정책을 적용하세요. 서버는 네트워크가 보고를 거부하는 경로 제약을 알 수 없습니다.

조각화를 정상적인 해결책으로 의존하지 마세요. RFC 8900은 IP 조각화가 운영상 취약성을 초래함을 설명합니다. MTU를 맞추고 PMTUD를 유지하거나 전송 계층에서 안전하게 프로브하는 것이 모든 중간 장치가 조각을 전달하고 재조립할 것이라 가정하는 것보다 더 견고합니다.

한 쪽 라우터를 변경할 수 없는 경우, 터널 또는 포워딩 경계에서 MSS 클램핑이 실용적인 TCP 해결책이 될 수 있습니다. 보편적인 숫자를 복사하지 말고 실제 경로에서 설정하세요. 이는 과도한 크기의 UDP 데이터그램을 복구하지 못하며, 불필요하게 낮은 값은 패킷과 헤더 오버헤드를 증가시키므로 캡처와 애플리케이션 테스트로 개선 여부를 확인해야 합니다.

서버, VM, 컨테이너 설정은 반드시 일치해야 합니다.

물리 NIC, 본딩, VLAN, 브리지, VM 어댑터, 컨테이너 네트워크, 터널의 MTU를 모두 점검하세요. 캡슐화를 올바르게 처리하는 계층에서는 값이 수치상 동일할 필요는 없지만, 내부 계층에서 생성된 패킷이 다음 계층에서 전달 불가능하거나 너무 크다고 보고되어서는 안 됩니다.

Docker의 경우 네트워크를 생성할 때 또는 데몬 구성에서 적절한 MTU를 설정한 후, 필요한 경우 영향을 받는 네트워크와 컨테이너를 다시 생성하세요. Civo의 문제 해결 예시는 기저 네트워크를 무시하는 Docker MTU가 예상치 못한 연결 문제를 일으킬 수 있음을 보여줍니다. 구성만 편집하는 것으로는 실행 중인 네트워크가 변경되었음을 증명할 수 없으니, 이후 라이브 인터페이스를 반드시 확인하세요.

성능 조정은 수리와 분리하세요. ZimaSpace의 장거리 링크에서 TCP 윈도우 크기 설명은 비행 중인 데이터 양에 관한 것이며, MTU는 패킷 크기를 제어합니다. 버퍼를 늘린다고 해서 너무 큰 패킷이 작은 링크를 통과할 수는 없습니다.

손상된 단계를 찾는 검사

일관되게 통과하는 가장 큰 패킷을 찾으세요

플랫폼에 맞는 ping 옵션을 사용해 페이로드 크기를 설정하고 지원되는 경우 단편화를 금지하세요. 결과를 인터페이스 MTU와 비교할 때 IP 및 ICMP 헤더 바이트를 추가하는 것을 잊지 마세요. 실패가 발생하는 동일한 클라이언트 경로에서 여러 크기를 테스트하세요. 반복 가능한 임계값이 한 번 성공한 기본 ping보다 더 유용합니다.

LAN, VPN을 통해, 그리고 컨테이너나 VM 내부에서 테스트를 반복하세요. 임계값이 한 경계에서 변경된다면 그 계층이 주요 의심 대상입니다. 일부 네트워크는 에코 트래픽을 속도 제한하거나 차단하므로 TCP 애플리케이션 요청이나 목적에 맞는 경로 MTU 도구로 결과를 확인하세요.

인터페이스, 경로 및 캡슐화를 검사하세요

영향받는 목적지에 대해 선택한 경로와 출구 인터페이스를 기록하세요. 패킷이 통과하는 모든 가상 및 물리 인터페이스, 터널 및 컨테이너 네트워크 구성을 검사하세요. 정책 라우팅이나 분할 터널링이 활성화된 경우 기본 경로가 사용된다고 가정하지 마세요.

외부 IP 버전과 전송을 포함한 실제 터널 스택의 헤더 오버헤드를 계산하세요. 안전한 내부 MTU는 외부 경로에서 이러한 헤더 공간을 남겨두어야 합니다. 터널이 경로를 변경한다면 지원하는 모든 하위 네트워크에서 작동하는 값을 선택하거나 작동하는 탐지 메커니즘을 유지하세요.

양쪽에서 데이터와 ICMP 피드백을 캡처하세요

송신자 근처와 좁은 링크로 의심되는 지점 이후에서 캡처하세요. 확인 응답 없이 반복되는 큰 패킷, ICMP 단편화 필요 메시지, 또는 ICMPv6 패킷 너무 큼 메시지를 찾으세요. 오류가 하류에서 발생하지만 송신자에게 도달하지 않는다면 반환 경로 및 방화벽 정책에 집중하세요.

TCP의 경우 SYN 및 SYN-ACK 패킷의 MSS 옵션을 검사하고 관찰된 데이터 세그먼트와 비교하세요. 낮은 MSS는 송신자가 너무 큰 TCP 패킷을 생성하지 못하게 할 수 있지만 UDP가 여전히 손상되었는지는 알 수 없습니다. 로드된 방화벽 규칙을 성공으로 간주하지 말고 캡처를 사용해 수리를 검증하세요.

MTU를 맞추거나 MSS를 고정한 후 다시 테스트하세요

더 작은 하위 레이어를 아는 인터페이스에서 MTU를 수정하는 것을 선호하세요. 생성 시 MTU가 고정된 가상 네트워크는 재생성하세요. 불가능하다면 포워딩 또는 터널 경계에서 TCP MSS를 클램핑하고 필요한 ICMP 피드백을 허용하세요. 결과를 명확히 하기 위해 한 번에 한 가지 변경만 하세요.

핑뿐만 아니라 원래 작업 흐름을 다시 테스트하세요. TLS 협상을 완료하고 한 패킷보다 큰 응답을 로드하며 파일을 업로드 및 다운로드하고 재전송을 관찰할 만큼 충분히 연결을 유지하세요. 부분 연결은 이를 드러낸 애플리케이션이 양방향으로 데이터를 안정적으로 전송할 때만 해결됩니다.

부분 연결이 심각한 문제가 될 때

백업, 복원, 원격 관리, 동기화 또는 인증에 영향을 미칠 때 문제를 긴급하게 다루세요. 이러한 작업 흐름은 초기 검사를 통과할 수 있지만 의미 있는 데이터가 이동하기 시작한 후에만 실패하여 불완전한 복사본이나 운영자가 저장소 또는 자격 증명 오류로 오해할 수 있는 타임아웃을 남깁니다.

IPv6가 IPv4와 다르게 동작하거나 VPN 전용 경로가 실패하거나 컨테이너 트래픽이 호스트 트래픽과 다를 때도 우선순위를 두세요. 이러한 차이는 사용 가능한 패킷 크기를 변경하는 경로나 캡슐화를 드러냅니다. 경계가 더 결정적일수록 네트워크 경로를 수리하지 않고 애플리케이션을 계속 재시도하는 것은 덜 유용합니다.

자주 묻는 질문

웹사이트가 로드되지 않을 때 홈 서버에 핑이 가능한 이유는 무엇인가요?

기본 핑 패킷은 작고 DNS 교환과 TCP 핸드셰이크도 작습니다. TLS나 HTTP가 경로 한계보다 큰 패킷을 보낼 때만 웹사이트가 멈출 수 있습니다. 더 큰 비분할 프로브를 테스트하고 실패한 웹 연결을 캡처하여 한 번의 핑 응답만으로 모든 패킷 크기가 작동한다고 판단하지 마세요.