값을 추측하지 않고 의심되는 VPN MTU 문제를 시험하기

인터넷 MTU 값 목록을 어느 하나가 더 빠르게 느껴질 때까지 시도하는 것은 시험이 아니라 정지 규칙이 없는 탐색입니다. 효과가 있는 방법은 통제된 크기 조건 하나를 바꾸고 결과를 같은 경로와 비교합니다. 반복 가능하고 무해한 실패에서 시작하고, 실험을 되돌릴 수 있는 동작하는 구성을 유지하십시오. 아래의 모든 내용은 그 규율을 전제로 하며, 그것이 없으면 변호할 수 없는 숫자만 남습니다.

숫자를 바꾸기 전에 경로를 고정하십시오

설정을 건드리기 전에 장치, 접속 회선, 터널 프로토콜, 종단점, 목적지, 주소 체계를 적어 두십시오. 이 여섯 가지 사실이 경로이며, 다른 경로를 겨냥한 검사는 다른 문제를 측정합니다. 또한 결과를 재현 가능하게 만들고, 그것이 시험과 반나절의 만지작거림을 구분합니다. 메모는 터미널 옆에 두고 머릿속에 두지 마십시오.

실행이 허용된 가장 좁은 시험부터 시작하십시오. 서버 측 변경은 그 종단점의 모든 사용자에게 닿으므로 조사의 끝에 속하고 처음이 아닙니다.

직접 통제하는 크기로 검사하십시오

Linux에서는 검사가 ping -M do -s 1400 host 형태이고, Windows에서는 ping -f -l 1400 host 형태입니다. 설정하는 것은 페이로드이며, 패킷 크기가 아닌 것은 IP와 ICMP 헤더가 위에 더해지기 때문입니다.

포럼 게시물에서 플래그를 복사하지 말고 눈앞의 시스템 문서를 읽으십시오. 직접 통제하는 목적지를 골라야 응답이 없는 것이 수수께끼가 아니라 신호가 됩니다. 정확한 명령과 정확한 크기를 경로와 같은 메모에 기록하십시오. 크기가 없는 결과는 일화일 뿐입니다. 한 번의 실행에서 두 가지를 바꾸면 어느 것이 결과를 냈는지 알 수 없습니다.

실패한 검사는 MTU 한계의 증거가 아닙니다

버려진 검사는 크기 한계가 아니라 ICMP 필터링을 뜻할 수 있습니다, 그리고 그 실수는 사람들을 한 번도 문제가 아니었던 값을 조정하게 만듭니다. 무엇이든 바꾸기 전에 검사를 실제 응용 프로그램과, 크기와 관련된 오류 메시지나 범위를 좁힌 캡처와 비교하십시오. 성공한 작은 ping도 한계보다 한참 아래에 있을 수 있으므로 아무것도 증명하지 못합니다. 구성이 움직이기 전에 독립적인 관측 두 번이 최소입니다.

검사가 성공하는데 응용 프로그램이 실패한다면, 그 경로에서 단순한 크기 한계가 아니라는 증거가 있습니다. 후보 변경의 가지 전체가 사라지므로 그것을 적어 두십시오.

클라이언트가 이미 지원하는 매개변수 하나만 조정하십시오

클라이언트가 이 프로토콜에 대해 문서화한 설정을 바꾸고 종단점과 목적지는 그대로 두십시오(그렇지 않으면 두 가지를 한꺼번에 바꾼 것입니다). TCP의 MSS 클램프는 모든 UDP 부하를 덮지 않으므로, 동작하기 시작한 브라우저가 터널 프로토콜을 그대로 망가뜨린 채 둘 수 있습니다. IPv4와 IPv6는 여기서 별개의 경로이며, 어떤 라우팅이 작동하기 전에 이미 헤더가 다르기 때문입니다.

둘 다 게시한다면 두 체계를 모두 시험하십시오. 한쪽의 결과는 다른 쪽에 대해 아무것도 말해 주지 않습니다. 오늘 밤 이 경로에서 통한 값은 하나의 데이터일 뿐이며 전체 VPN의 MTU가 아닙니다. 성공한 전송 한 번만으로 전역 설정으로 승격하지 말고, 값은 그것이 나온 경로 옆에 적으십시오.

되돌리기, 확인, 기록

비교가 가설을 뒷받침하지 않으면 원래 값을 되돌려 놓으십시오. 네트워크 관리자가 다른 곳에 영구 재정의를 저장하지 않았는지 확인하십시오. 실험이 정책이 되는 경로가 바로 그곳입니다. 다시 연결하고 시험하던 것만이 아니라 일반 응용 프로그램도 써 본 뒤, 증상, 실제 적용되는 경로, 이전 값과 새 값, 결과의 재현성을 기록하십시오.

누군가 변경을 넓히기 전에 그 기록을 변경 요청과 함께 보관하십시오.경로 MTU 탐색 메커니즘은 RFC 1191에서 더 작은 값이 한 경로를 살리고 다른 경로에는 아무것도 하지 않는 이유를 설명하며, 숫자 목록은 그 모델을 대신하지 못합니다. 경로, 크기, 관측, 그리고 복원한 값을 말할 수 있을 때 시험이 끝납니다.