프로파일의 세 줄은 모두 압축을 끄는 것처럼 보이지만, 실제로 그렇게 하는 것은 그중 하나뿐입니다. 차이가 중요한 이유는 무음으로 만들고 싶은 경고가 증상일 뿐이고, 상대방이 여전히 압축할 수 있는지를 결정하는 것은 정책이기 때문입니다. 변경 후 각 옵션이 무엇을 허용하는지라는 하나의 축으로 비교하면 모호함의 대부분이 사라집니다. 어느 것을 원하는지는 마이그레이션 중인지 정착 중인지에 달려 있습니다.

설정 파일에서 비슷해 보이는 세 가지 정책

각 옵션은 다른 질문에 답합니다. allow-compression no은 압축된 페이로드를 즉시 거부하고, allow-compression asym은 들어오는 것은 압축 해제하되 나가는 것은 절대 압축하지 않으며, 오래된 comp-lzo no은 상대방의 push로 압축을 켤 여지를 남깁니다. 서버가 무시할 수 없는 정책은 첫 번째뿐입니다.

이름이 비슷해 검토자를 오도할 수 있으므로 선택하기 전에 세 가지를 표로 적으십시오. 그중 둘은 여전히 수신 패킷에 대해 압축 해제 코드를 실행하며, 보안 논점은 바로 그 부분입니다. 세 번째는 방향을 제한하는 대신 기능 자체를 없앱니다. 변경 기록에 압축이 비활성화되었다고 적혀 있다면, 그 문장을 만족하는 행은 정확히 하나입니다.

조사를 시작한 경고는 목표가 아닙니다. 관대한 정책을 남긴 채 경고를 무음으로 만들면 깨끗한 로그와 변하지 않은 노출이 남습니다.

SettingWhat it permitsWhen it is the right answer
allow-compression noNo compressed payloads, and no compression framing under offloadBoth ends can be changed now
allow-compression asymDecompress inbound onlyA dated migration while peers catch up
comp-lzo noOff locally, still pushable by a peerLegacy compatibility you can still justify

오래된 LZO 옵션에서 no의 의미

더 이상 권장되지 않는 LZO 옵션에서 no는 로컬 측의 압축을 끄지만, 정책이 허용하는 곳에서 상대방이 그것을 켜는 것을 금지하지는 않습니다. 이 비대칭 때문에 프로파일을 엄격한 거부로 옮기면 단일 서버 실험실 테스트로는 결코 드러나지 않을 방식으로 동작이 바뀝니다.

보안 우려는 절대적이 아니라 조건부입니다. 공격자가 선택한 평문을 비밀 옆에 두고 압축이 암호화된 트래픽의 크기를 어떻게 바꾸는지 관찰할 수 있다면 정보 경로가 존재합니다. LZO에서 LZ4로 옮기는 것은 알고리즘과 프레이밍을 바꾸는 것이지 그 메커니즘을 바꾸는 것이 아닙니다.

따라서 정직한 틀은 지금 어떤 알고리즘이 권장되는지가 아니라 무엇을 허용할 의향이 있는지에 관한 것입니다. 엄격한 거부만이 상대방의 협조에 의존하지 않는 선택입니다.

수신 전용은 마이그레이션 상태이지 목적지가 아닙니다

비대칭 수용은 한쪽이 압축을 멈추는 동안 다른 쪽이 여전히 그것을 기대하기 위해 존재합니다. 그것은 다리이며, 다리에는 종료일과 소유자가 필요합니다. 정책이 바로 그 트래픽을 허용하므로 어떤 피어가 아직 압축 트래픽을 보내는지 기록하십시오. 그 목록이 없으면 마이그레이션 상태는 관성으로 영구 설정이 됩니다.

클라이언트는 자기 파일을 편집해서 호환되지 않는 서버가 오래된 프레이밍을 포기하도록 강제할 수 없습니다. push 방향은 서버에서 결정되므로 마이그레이션은 실제로 서버 설정과 클라이언트별 파일에서 끝납니다.

stub 모드는 프레이밍을 유지하면서 압축 작업 자체를 건너뛰며, 이전 옵션의 직접적인 대체물이 아닙니다. 하나를 선택하기 전에 아직 지원해야 하는 가장 오래된 피어에 대해 시험하십시오.

데이터 채널 offload가 답을 바꾸는 지점

데이터 채널 offload는 패킷 처리를 커널로 옮기며, 여전히 압축 프레이밍에 의존하는 프로파일은 그 경로에 맞지 않을 수 있습니다. 실패가 항상 요란하지는 않으며, 클라이언트가 연결된 뒤 시험한 터널과 다르게 동작합니다.

연결이 성공하는지만 보아서는 부족하며, 변경 전후에 어느 구현이 활성인지 확인하십시오. offload 경로가 압축 프레이밍을 거부할 때 엄격한 거부 정책과 offload 배포는 일치하지만, 관대한 정책과 offload 배포는 일치하지 않습니다.

올바르게 보이는 파일이 조용히 사용되지 않는 파일이 되는 곳이 바로 거기이므로 그 조합은 별도의 시험이 필요합니다. 협상된 상태는 로그에 둘 중 하나만 보이므로 프로파일에 기록된 의도와 비교하십시오.

정책을 고른 다음 협상된 결과를 검증하십시오

양쪽 끝을 바꿀 수 있으면 엄격한 거부를, 아직 아니면 비대칭 수용을, 완전한 압축은 노출이 왜 허용 가능한지 설명할 수 있을 때만 고르십시오. 그다음에는 파일이 말하는 것이 아니라 협상된 것을 검증하십시오. 더 조용한 로그는 배포하려 했던 정책과 일치할 때만 증거입니다.

그 결정을 적용 대상 프로파일 옆에 날짜와 아직 예외인 피어와 함께 두십시오. 반년 뒤 그 메모는 의도적인 예외와 아무도 날짜를 말할 수 없는 사고를 가르는 차이입니다. 프로파일과 같은 저장소에 적어 두면 다음 편집자가 지시보다 먼저 이유를 봅니다.

관련 글