VPN 처리량 저하가 엔트로피 문제인가? 대개 아니다

터널을 통한 느린 처리량과 난수를 기다리며 멈춘 기계는 매우 다른 경험을 만들지만, 같은 불만 아래 기록됩니다. 하나는 무언가 작동하기 전의 멈춤으로 나타납니다. 다른 하나는 작동하며 보는 동안 계속 데이터를 느리게 옮기는 연결로 나타납니다. 어느 쪽인지 판단하는 데는 십 분이 걸리고 일주일의 추측을 아낍니다.

비슷해 보이는 두 증상

새로 부팅한 뒤 연결을 하나도 받기 전에 멈추는 서비스는 무언가를 기다리고 있습니다. 빠르게 연결된 뒤 기대 속도의 일부로 전송하는 터널은 다른 무언가에 의해 제한됩니다. 암호화라는 단어가 두 이야기 모두에 나오기 때문에 둘이 합쳐집니다. 설정 파일을 건드리기 전에 둘을 분리하십시오.

시작, 인증, 키 재협상, 전송 자체 주위에 타임스탬프를 두십시오. 터널을 쓸 수 있게 되기까지의 긴 지연은 낮은 정상 속도가 아니며, 둘을 하나의 숫자로 평균 내면 증거가 파괴됩니다.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

처음 두 명령은 시작 작업을 시간선 위에 놓습니다. 세 번째는 커널의 엔트로피 회계 값을 출력하는데, 이는 단일 데이터 점으로는 유용하고 대역폭 측정기로는 쓸모없습니다.

난수 대기가 실제로 어떻게 보이는가

안전한 난수 바이트 요청은 커널이 난수 원천을 초기화할 때까지 차단될 수 있습니다. 이는 부팅 초기에 환경 잡음이 거의 모이지 않은 가상 머신과 작은 임베디드 보드에서 가장 중요합니다. 그렇다고 해서 암호화된 모든 바이트가 새 엔트로피를 소비하는 것은 아닙니다.

현대의 생성기는 한 번 시드한 뒤 결정론적 구성에서 출력을 만들고, 자체 일정에 따라 다시 시드합니다. 대량 전송은 풀을 바이트 단위로 고갈시키지 않습니다이므로 느린 전송 중의 낮은 풀 값은 원인에 대해 아무것도 증명하지 못합니다.

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

첫 명령은 보는 동안 프로세스가 난수 호출에 머물러 있는지 보여 줍니다. 둘째는 커널 자체의 초기화 메시지를 보여 주며, 바로 거기서 초기 부팅 멈춤이 드러납니다.

커널 버전과 서비스가 실제로 링크하는 라이브러리를 기록하십시오. 동작이 구현과 릴리스마다 다르므로, 복구 후에 찍은 추적은 보통 멈춤을 완전히 놓칩니다.

지속되는 느림이 실제로 어떻게 보이는가

내내 느리게 전송하는 터널은 데이터 경로에 의해 제한됩니다. 포화된 스레드 하나, 외부 패킷 손실, 재전송, 가득 찬 소켓 큐가 각각 그 패턴을 만들며, 각각 고유한 해결책이 있습니다. 집계된 CPU 비율은 바쁜 스레드 하나를 감추며, 이것이 가장 흔한 오독입니다. 총 부하를 보기 전에 스레드별 시간을 보십시오.

비교 가능한 기준선으로 양방향을 측정하고, 애플리케이션 자체의 보고 대신 인터페이스 카운터를 보십시오.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

첫 명령은 한 피어의 큐와 혼잡 상태를 보여 줍니다. 둘째와 셋째는 스택과 인터페이스에서 드롭과 재전송을 보고하며, 원인이 보통 가장 먼저 나타나는 곳입니다.

측정한 병목에 맞는 수정을 고르십시오

증거가 초기 부팅 초기화를 가리키면, 가상 머신에서는 호스트가 제공하는 난수 장치도 포함할 수 있는 플랫폼 지원 시드 경로를 보십시오. 여러 게스트에 그대로 복사한 시드 이미지는 독립적 초기화를 대신하지 못합니다.

증거가 데이터 경로를 가리키면 카운터가 지시하는 것을 조정하십시오. 버퍼 크기는 큐가 넘칠 때 도움이 되고 스레드 하나가 포화되면 아무것도 하지 않습니다. 카운터를 올리려고 엔트로피 데몬을 설치하는 것은 처리량 수리가 아니며, 그래프를 좋게 보이려고 시드 가정을 바꾸는 것은 보안 속성을 숫자와 맞바꾸는 일입니다.

같은 측정이 같은 조건에서 개선될 때만 변경을 받아들이십시오. 더 큰 카운터는 결과가 아니며, 측정된 대기가 더 짧아지거나 원인이 확인된 더 빠른 전송이 결과입니다.