랩 VPN은 연결됐지만 코스 도구는 여전히 실패한다

VPN은 연결됐다고 하고, 코스 대상은 ping에 응답하며, 랩 도구는 여전히 오류로 종료된다. 터널과 지원되는 런타임은 서로 다른 두 가지 요구 사항이기 때문에 이런 조합은 교육 환경에서 흔하다. 하나는 패킷 경로를 증명하고, 다른 하나는 그 프로그램이 이 머신에서 애초에 실행될 수 있는지를 증명한다. 이 실패를 VPN 문제로 취급하면 잘못된 적 없는 네트워크 설정을 바꾸러 가게 된다.

연결 표시가 실제로 증명하는 것

VPN 연결은 클라이언트가 게이트웨이에 도달해 라우팅과 주소 지정을 받았다는 것을 증명한다. 실습에 나중에 어떤 포트가 필요한지, 도구가 운영 체제와 맞는지, 그 아키텍처와 라이브러리가 있는지는 말해 주지 않는다. 그것들은 애플리케이션의 사실이다. 코스의 기준 검사가 통과하는데도 도구가 계속 실패한다면 남는 질문은 연결성이 아니라 호환성이다.

연결 배지는 둘 모두에 대한 증거로 착각하기 쉬우니, 둘 중 무엇을 실제로 시험했는지 적어 두라.

먼저 코스의 문서화된 경로를 확인하라

강사가 공개한 검사를 실습을 실행하는 바로 그 머신이나 작업 공간에서 사용하라. 다른 환경을 시험하고 그것을 동등하다고 부르는 일을 피할 수 있다.

ip route get 10.50.20.15
nc -vz 10.50.20.15 8080

경로 조회는 실습 트래픽이 어느 인터페이스를 쓸지 보여 주고, 포트 검사는 그 특정 서비스가 연결을 받아들이는지 보여 준다. 잘못된 인터페이스를 가리키는 경로는 실패를 설명하고, 올바른 경로에서 거부되는 포트는 서비스나 그 정책을 가리킨다. 예시 주소는 할당된 대상 범위로 바꾸고, 검사가 사용한 출발지 주소를 기록하라. 범위 안의 다른 호스트로 보내는 ping은 같은 시험이 아니다.

그다음 도구를 지원 매트릭스와 대조하라

경로가 증명되면 실습이 실제로 실행하는 프로그램을 살펴보라. 아키텍처와 라이브러리 불일치는 요란하게 실패하며 타임아웃으로 잘못 읽기 쉽다.

uname -m
file ./lab-tool
ldd ./lab-tool

머신 유형은 어떤 바이너리 형식이 실행될 수 있는지 알려 주고, 파일 보고서는 도구의 형식과 아키텍처를 밝히며, 라이브러리 목록은 의존성이 해결되는지 보여 준다. 64비트 전용 이미지 위의 32비트 바이너리나 빠진 공유 라이브러리는 터널과 아무 관련 없는 오류를 만든다. 릴리스와 플랫폼은 다른 버전에 관한 포럼 글이 아니라 코스 지원 매트릭스와 비교하라. 이 증거를 모으는 동안 실습의 권한은 그대로 두라.

소유자에게 두 가지 발견을 나눠 전달하라

교육 지원은 깔끔한 분리, 즉 네트워크 기준선이 보여 준 것과 도구 환경이 보여 준 것으로 움직일 수 있다. 정리된 경로와 포트 결과, 정확한 오류 문구, 바이너리 검사의 플랫폼 세부 정보를 포함하라. 자격 증명과 비공개 구성 번들은 진단에 도움이 되지 않으면서 위험만 더하므로 빼라. 그다음 환경을 고칠지 실습을 조정할지 소유자가 결정하게 하고, 할당된 범위를 넓히거나 주장을 증명하려고 다른 참가자의 머신을 빌리지 말라.

원인이 하나뿐이어도 티켓에는 두 발견을 모두 기록하라. 그러면 다음 시도는 추측이 아니라 증거에서 시작한다.