iPhone VPN의 MTU: 숫자를 바꾸기 전에 소유자를 정하세요

iPhone VPN 패킷 크기에 관한 모든 논의는 결국 ppp0이라는 인터페이스에 대한 같은 Mac 명령을, 보통 숫자를 붙여 제안합니다. 그것은 그대로 옮겨지지 않으며, 그 인터페이스가 문제의 연결에 속하지 않는다면 Mac에서도 올바른 제어가 아닙니다. 휴대폰에서는 숫자를 터널을 구현하는 쪽이 소유합니다. 네이티브 프로필이면 운영체제, 앱이면 패킷 터널 제공자, 문서화된 속성이 협상되면 게이트웨이입니다. 그중 어느 경우인지는 세 가지 질문으로 정해집니다.

첫 번째 질문: 어떤 클라이언트가 실행 중인가

네이티브 IKEv2 프로필, 내장 Cisco IPsec 프로필, 서드파티 Cisco 클라이언트는 지원되는 속성 집합이 각각 다른 세 가지 구현입니다. 설정의 프로필 유형은 휴대폰이 실제로 무엇을 시작했는지 알려 주고, 앱 목록은 경로에 제공자가 있는지 알려 줍니다. 거기서 시작하세요. 나머지 결정이 거기서 나오기 때문입니다. 앱 목록에 제공자가 없으면 터널은 운영체제 소유입니다.

게이트웨이 공급업체로 구현을 추론하지 마세요. Cisco 헤드엔드는 공급업체 이름 말고는 공통점이 없는 클라이언트의 연결도 종료할 수 있습니다. 오래된 릴리스의 오래된 빌드 스크린샷은 그 조합이 무엇을 지원했는지 알려 줄 뿐, 손에 든 휴대폰이 무엇을 하는지는 알려 주지 않습니다.

두 번째 질문: 그 값을 누가 소유하는가

Apple은 네트워크 확장 설정 객체를 통해 패킷 터널 개발자에게 MTU 속성을 제공합니다. 이는 자기 터널을 구성하는 제공자를 위한 API이며, 사용자나 관리자가 다른 사람의 설치된 클라이언트에서 켤 수 있는 스위치가 아닙니다. 서드파티 앱은 이를 노출하거나 무시하거나 값을 하드코딩할 수 있습니다.

네이티브 프로필에서는 운영체제가 인터페이스 크기를 고르고, 휴대폰은 그에 대한 편집기를 제공하지 않습니다. Cisco 원격 액세스 게이트웨이에는 연결 프로필에 대한 문서화된 속성이 있고, 그것이 적용되는지는 클라이언트, 릴리스, 협상된 전송에 달려 있습니다. 문서화된 것과 지켜지는 것 사이의 이 간극이 복사한 숫자가 틀어지는 곳입니다.

세 번째 질문: 증상이 크기에 의존하는가

크기 문제에는 서명이 있습니다. 작은 요청은 성공하고, 큰 업로드나 큰 응답은 멈추며, 같은 서비스가 다른 액세스 네트워크에서는 동작합니다. 필터링, 앱의 페이로드 한도, 멈춘 서버도 비슷한 불만을 만들 수 있으므로 실패하는 작업 하나를 성공하는 작업 옆에 기록하세요. 앱이 시간과 크기를 보고한다면 둘 다 그것과 함께 적으세요. 그 짝이 없으면 이후의 모든 변경은 추측입니다.

같은 테스트를 Wi-Fi와 셀룰러에서 실행하세요. 네트워크를 따라가는 실패는 경로를 가리키고, 기기를 따라가는 실패는 클라이언트나 프로필을 가리키며, 둘은 서로 다른 소유자가 필요합니다. 두 실행 모두 같은 서비스와 같은 계정을 쓰세요. 아니면 비교가 아무것도 말해 주지 않습니다.

Mac 레시피가 계속 등장하는 이유

PPP 기반 데스크톱 VPN의 오랜 세월이 인터페이스 크기 변경을 정당한 로컬 우회로로 만들었고, 그 지침이 모바일 논의로 복사되었습니다. 휴대폰에는 셸도, 그런 인터페이스 이름도, 재연결 후의 지속성도 없습니다. 2011년에 데스크톱 문제를 해결한 레시피는 그것을 참으로 만든 조건보다 훨씬 멀리 여행했습니다. 논의가 무엇을 주장하든, 모바일 클라이언트는 이에 대해 어떤 셸 명령도 받아들이지 않습니다.

복사한 값을 설정이 아니라 경로에 대한 가설로 다루세요. 더 작은 크기가 전송을 동작시키고 더 큰 크기가 확실히 실패한다면 경로에 대한 증거는 있습니다. 그래도 그것에 작용할 권한이 있는 구성 요소를 찾아야 합니다. 그 탐색은 보통 게이트웨이 프로필이나 앱 공급업체에서 끝나고, 휴대폰에서는 드뭅니다.

전송이 답을 바꾼다

세션이 IPsec가 아니라 TLS 위에서 동작한다면 게이트웨이의 TCP 세그멘테이션 조정이 도움이 될 수 있습니다. TCP 흐름에 대해 알리는 세그먼트 크기를 다시 쓰기 때문입니다. UDP 트래픽에는 아무 효과가 없고, 그쪽에 사람들이 생각하는 것보다 현대 웹의 더 많은 부분이 포함됩니다. 변경을 제안하기 전에 협상된 전송을 확인하고, 어떤 전송에 영향이 있을 것으로 보는지 티켓에 적으세요.

경로 MTU 탐색은 끝점이 추측 대신 실제 한도를 배우기 위해 존재합니다. 피드백을 막고 작은 크기를 하드코딩하는 것은 동작하는 큰 전송을 모든 연결에서 영구적이고 숨은 비용과 맞바꾸는 일입니다.

게이트웨이 팀에 무엇을 물어야 하나

세 가지를 요청하세요. 속성의 정확한 이름과 범위, 배포된 클라이언트가 그것을 지키는지, 세션이 어떤 전송을 협상했는지입니다. 하나의 그룹 정책에 적용한 변경은 검증할 수 있지만 전역 편집은 그럴 수 없고, 문제를 보고한 적 없는 사용자에게 위험을 옮깁니다. 문서 참조도 요청하세요. 속성 이름은 릴리스 사이에 바뀝니다.

그다음 한 가지만 바꾸고 원래 실패한 작업을 다시 테스트하세요. 속도 테스트 다운로드가 아닙니다. 클라이언트 버전과 액세스 네트워크와 함께 변경 전후 기록을 남기면, 다음 보고서는 다시 논쟁하는 대신 비교될 수 있습니다.

원래 크기에서도 작업이 실패한다면 크기가 원인이 아니었습니다. 그 결론도 기록하세요. 다음 사람이 같은 가설을 다시 열지 않도록.