터널 MTU를 낮출 때까지 OpenConnect 페이지가 멈추는 이유

로그인은 성공하고 포털 첫 페이지는 그려지는데, 그다음 대시보드 위젯이나 보고서가 waiting for host 상태로 남아 브라우저가 포기할 때까지 기다립니다. 공개 사이트는 그동안 내내 정상적으로 로드되고, 자격 증명은 아무것도 바뀌지 않았습니다. 큰 응답이 멈추는 동안 작은 응답이 도착하는 것은 접근 규칙이 아니라 패킷 크기 상한의 징후입니다. 프로필의 다른 무엇을 수정하기 전에 이 판단을 확인하십시오.

크기 문제와 정책 문제를 분리하라

거부 가능성을 먼저 배제하십시오. 게이트웨이가 거부했다면 페이지가 반쯤 로드되는 대신 연결이 즉시 실패했을 것입니다. 터널이 올라온 뒤 더 큰 전송에서만 멈춘다면, 바깥 경로가 안쪽 패킷을 실을 수 없다는 뜻입니다.

메커니즘은 캡슐화입니다. 안쪽 패킷마다 터널 헤더가 붙으므로 물리 링크에 맞던 페이로드가 더는 맞지 않는 바깥 패킷이 되고, do-not-fragment 비트를 가진 것은 브라우저가 해석할 수 있는 응답 없이 버려집니다.

do-not-fragment 프로브로 상한을 측정하라

추측하지 말고 상한을 측정하십시오. 단편화를 거부하는 프로브를 보내고 응답이 돌아올 때까지 페이로드를 단계적으로 낮추되, 다음과 같은 명령에서 시작하십시오: ping -M do -s 1472 host. DF가 설정된 상태에서 단편화가 필요하다고 불평하는 응답은 값이 아직 너무 높다는 뜻입니다. 1462에서, 다음으로 1452에서 반복하고, 응답이 오는 첫 크기에서 멈추십시오. 번호는 시험한 호스트와 함께 기록하십시오. 왜냐하면 그 답은 그 경로에 속하고 프로토콜 전반에 속하지 않기 때문입니다.

터널이 실제로 트래픽을 보내는 주소를 조사하십시오. 게이트웨이의 공개 이름에 대한 바깥 프로브와 내부 서버에 대한 안쪽 프로브는 서로 다른 홉을 측정하며, 어느 한쪽의 ICMP 필터링이 건강한 경로를 끊긴 것처럼 보이게 할 수 있습니다.

값을 터널 장치에 적용하라

결과는 Wi-Fi 어댑터가 아니라 클라이언트가 만든 인터페이스에 적용하십시오. Linux 클라이언트에서는 ip link set dev tun0 mtu 1300 에 이어 ip link show tun0 를 실행해 값이 반영되었는지 확인합니다. 장치 이름은 구현과 터널 구성 방식에 따라 달라지므로 클라이언트가 보고하는 이름을 쓰십시오.

터널 MTU를 낮추면 각 패킷이 싣는 페이로드가 줄어들어 전체 처리량이 조금 떨어지며, 그것이 큰 응답을 블랙홀에 버리지 않기 위한 대가입니다. 더 작은 숫자가 자동으로 더 안전한 것은 아닙니다. 대신 물리 어댑터를 바꾸면 그 링크의 모든 연결에 피해가 퍼지는 반면, 너무 큰 안쪽 패킷은 그대로 큽니다.

먼저 클라이언트 자체의 MTU 요청을 사용하라

호출을 직접 제어한다면 클라이언트가 나중에 패치되는 대신 크기를 요청할 수 있습니다. --mtu 는 서버에 터널 MTU를 요청하고, --base-mtu 는 하위 경로의 MTU를 선언해 게이트웨이가 터널 수치를 도출할 수 있게 합니다. 둘 다 요청이며, 클라이언트의 매뉴얼 은 게이트웨이가 어느 쪽도 존중하리라고 약속하지 않습니다.

이 차이가 작업 순서를 정합니다. 먼저 요청을 시도하고 그것이 만드는 인터페이스를 확인한 다음, 게이트웨이가 고른 값이 여전히 멈춘다면 장치를 로컬에서 설정하는 쪽으로 돌아가십시오.

실패한 전송으로 검증하고, 그다음 영구화하라

로컬 ip link 변경은 클라이언트가 터널을 다시 만들 때까지 유지되며, 이는 다음 재연결이나 재개 시에 일어납니다. 값을 연결이 시작되는 곳에 두십시오: 클라이언트를 실행한 뒤 장치를 조정하는 래퍼, ExecStartPost 단계가 있는 systemd 유닛, 또는 게이트웨이가 받아들일 때의 클라이언트 옵션입니다. 프로필 옆에 버전 관리로 두어 다음 사람이 숫자가 왜 있는지 볼 수 있게 하십시오.

첫 페이지가 아니라 실패한 요청으로 시험하십시오. 보고서를 열거나, 첨부를 내려받거나, 멈췄던 저장소 가져오기를 실행하고, 여전히 멈춘다면 정확히 어디서 멈추는지 적어 두십시오. 변경 후 그려지는 페이지는 거의 아무것도 증명하지 못합니다. 변경 전에도 그려졌기 때문입니다.

같은 전송이 같은 지점에서 멈춘다면, MTU 이론은 입증되지 않은 것입니다. 터널에서 트래픽을 캡처하고 숫자를 다시 바꾸기 전에 어느 쪽이 전송을 멈추는지 확인하며, 이전 값을 기록해 두어 롤백이 한 명령으로 끝나게 하십시오.