OpenVPN UDP 터널 안에서 TCP를 쓰는 NFS: 두 가지 전송

UDP를 나르는 터널 안에서 TCP를 쓰는 NFS 대화를 나르는 것은 완전히 일관되며, 동시에 두 가지 전송을 언급하기 때문에 사람들을 혼란스럽게 합니다. TCP는 클라이언트와 NFS 서버 사이의 파일 서비스 대화입니다. UDP는 VPN 끝점 사이의 암호화된 전송로입니다. 어느 것도 다른 하나에 대해 무엇도 함의하지 않습니다.

무엇이든 디버깅하기 전에 둘을 따로 적어 두세요——이런 장애의 대부분은 누군가 잘못된 계층을 바꾸면서 시작됩니다.

두 계층, 두 설정

마운트 옵션 proto=tcp은 NFS 클라이언트가 NFS 서버와 어떻게 대화하는지를 설명합니다. VPN 프로필의 proto udp 설정은 터널 끝점이 캡슐화된 패킷을 어떻게 교환하는지를 설명합니다. 마운트 옵션을 바꿔도 터널은 바뀌지 않으며, 터널의 전송을 바꿔도 NFS 클라이언트가 협상한 내용은 바뀌지 않습니다. 유효한 마운트 옵션은 fstab 줄이 아니라 nfsstat -m로 확인하고, VPN 전송은 실제로 사용 중인 프로필에서 확인하세요.

그다음 둘을 장애 노트에 별개의 항목으로 기록하세요. 겉으로 보이는 개선은 노트가 어느 계층이 바뀌었는지 밝힐 때만 추적할 수 있습니다.

둘러보기는 대량 읽기가 아니다

디렉터리 목록은 일부 작업이 완료되었음을 증명합니다. 지속적인 읽기, 쓰기, 잠금, 또는 저장소 백엔드가 같은 조건에서 완료된다는 것을 증명하지는 않습니다. 큰 파일의 중간에서 멈추는 것은 결코 성공하지 않는 마운트와 다른 관찰이며, 서로 다른 계층을 가리킵니다.

실패하는 작업을 정확히 기술하세요. 경로, 방향, 멈춤의 대략적 지점, 그리고 클라이언트, 서버, VPN 로그의 마지막 관련 이벤트를 적고, 그런 다음 트래픽이 계속되는 곳과 멈추는 곳을 비교하세요.

MTU는 가설이지 진단이 아니다

패킷 크기에 의존하는 손실은 터널이 큰 세그먼트를 나를 때 실제로 가능하며, 둘러보기는 되지만 읽기는 멈추는 패턴을 정확히 만들어 냅니다. 그러나 그 패턴은 MTU 문제를 증명하지 않습니다——서버가 느릴 때, 방화벽이 오래된 연결을 시간 초과로 끊을 때, 또는 디스크가 바쁠 때도 같은 모양이 나타나기 때문입니다. 모든 곳에서 MTU를 낮추고 승리를 선언하는 대신 통제된 시험으로 가설을 검증하세요.

시간 초과만으로는 UDP를 바꿔야 하는지에 대해 아무것도 말해 주지 않습니다. 그것은 여러 가능한 주인이 있는 증상입니다.

한 번에 하나의 변수만 바꾼다

전송을 비교할 때는 NFS 작업 부하와 다른 모든 설정을 안정적으로 유지하세요. 같은 유지보수 창에서 마운트 전송, 터널 프로토콜, MTU를 바꾸면 누구도 원인을 귀속시킬 수 없는 결과가 나옵니다. 같은 파일 작업을 전후에 실행하고 각 단계에서 결과를 기록하세요.

이전 값도 티켓에 남겨 두세요. 변경이 상황을 악화시킨다면 되돌림은 문서화된 숫자여야 하며, 예전에 어땠는지에 대한 누군가의 기억이어서는 안 됩니다.

실패한 계층을 읽는다

터널이 살아 있고 NFS 요청이 기다린다면 VPN이 실패한 것이 아니라 파일 서비스가 실패한 것입니다. 터널이 끊겼다면 NFS 요청의 실패는 원인이 아니라 결과입니다. 두 계층의 로그 줄을 맞춰 보는 것이 이 두 경우를 구별하는 가장 빠른 방법이며, 파일 관리자에서 추측하는 것보다 낫습니다.

결론을 두 문장으로 쓰세요. 계층마다 하나씩이면, 다음 사람이 어느 전송이 어느 것인지 다시 도출하지 않고 시험을 재현할 수 있습니다.