WireGuard 멈춤: MTU 한계인가, 빠진 포워딩 규칙인가?

WireGuard가 이상하게 동작하면 곧바로 MTU를 낮추는 습관이 있는데, 그 습관은 다른 결함을 가립니다. 전달하지 않는 게이트웨이와 큰 패킷을 나르지 못하는 경로는 구분 가능한 패턴을 만듭니다: 하나는 양방향 모두에서 모든 크기에서 실패하고, 다른 하나는 작은 요청에서 살아남고 큰 요청에서 죽습니다. 어떤 숫자를 바꾸기 전에 어느 형태인지 확인하십시오. 시험은 저렴하고 가능한 원인의 절반을 제거합니다.

두 가지 고장, 두 가지 형태

포워딩 문제는 서버 바로 뒤에서 나타납니다. 핸드셰이크는 성공하고 터널 주소가 응답하며 게이트웨이 뒤의 어떤 것도 작은 요청으로도 닿지 않습니다. 패킷은 서버에 도착했지만 전달되지 않았거나, 응답에 돌아갈 경로가 없었습니다.

크기 문제는 임계값 위에서만 나타납니다. DNS, TCP 핸드셰이크, 작은 API 호출은 동작하지만 파일 다운로드나 큰 응답은 멈춥니다. 들어간 패킷은 끝에서 끝까지 갔고, 들어가지 못한 패킷은 어딘가에서 쓸모 있는 보고 없이 버려졌습니다.

그 설명들은 서로 다른 사람과 서로 다른 구성 파일을 가리키므로 추측보다 형태를 재는 편이 낫습니다. 게이트웨이로 보내는 핑 한 번으로는 둘을 구분할 수 없습니다.

무엇이든 줄이기 전에 포워딩을 배제하십시오

게이트웨이 자체가 아니라 게이트웨이 너머의 목적지를 시험하십시오. 서버의 터널 주소로 보내는 핑은 인터페이스가 살아 있고 터널을 끝내는 기계에 닿는다는 것만 증명합니다. 더 넓은 네트워크의 트래픽은 그 기계에서 IP 포워딩이 켜져 있는지와 전달된 흐름을 허용하는 방화벽에 달려 있습니다. 둘 다 참이어야 하고, 하나라도 거짓이면 같은 침묵이 생깁니다.

반환 라우팅도 그만큼 중요합니다. 목적지 네트워크가 클라이언트의 터널 주소에 도달하는 방법을 모르면 요청은 도착하고 응답은 사라지며, 클라이언트는 버려진 포워딩과 똑같아 보이는 시간 초과를 보고합니다.

설계가 주소 변환을 쓰는 곳에서는 변환 규칙이 그 반환 경로의 일부입니다. MTU 문제를 쫓으면서 그것을 제거하면 동작하던 설계가 망가진 설계가 되므로, 편집하기 전에 기존 규칙을 읽으십시오.

끊김이 어디서 시작되는지 재십시오

먼저 포워딩 상태와 필터 규칙을 읽으십시오. 읽기 전용 점검이며 값싼 질문에 답합니다:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

그다음 클라이언트에서 게이트웨이 너머의 호스트를 향해 don’t-fragment 비트로 크기를 시험하십시오:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

첫 시험이 되고 두 번째가 단편화 오류로 실패하면 경로가 사용 가능한 크기를 알려 주는 것입니다. 둘 다 안 되면 포워딩이나 라우팅을 보는 것이며, MTU는 바꿀 변수가 아닙니다.

증명한 계층을 고치십시오

포워딩이 고장이면 수정은 포워딩 규칙이나 경로이며, 설계가 허용하는 만큼 좁게 표현합니다. 크기가 고장이면 수정은 이 특정 경로의 캡슐화를 고려한 MTU이며, 필요한 인터페이스에 적용하고 함대의 모든 어댑터에 적용하지는 않습니다.

어느 쪽이든, 그 뒤에 같은 목적지로 같은 작업을 반복하십시오. 원래의 큰 전송이 이제 완료되면 변경이 실패하던 계층을 다룬 것입니다. 작은 시험만 나아졌다면 증상을 치료한 것이고 실제 한계는 아직 그 자리에 있습니다.

변경 전에 어떤 형태를 보았는지 적으십시오. 수정 옆에 기록된 그 한 줄이 다음 사람이 결코 문제가 아니었던 MTU를 낮추지 못하게 막습니다.