VPN에서 Nmap 원시 스캔은 실패하는데 -sT 연결은 왜 될까?
원시 패킷 스캔과 일반 TCP 연결에는 서로 다른 권한이 필요합니다. 먼저 연결 확인을 실행하고, 각 플래그를 문자 그대로 읽은 뒤 결과에서 멈추십시오.
터널로 페이지는 열리는데 포트 스캔은 호스트를 다운으로 보고하며, 첫 직감은 VPN이 무언가를 막는다는 것입니다. 대개 VPN은 새로운 것을 막지 않습니다. 두 시험은 운영체제에 서로 다른 기능을 요구하고, 그 중 하나만 원시 패킷 접근이 필요합니다. 터널을 건드리기 전에 어느 기능이 실패했는지 먼저 밝힌십시오.
기능과 터널을 분리하십시오
일반 애플리케이션은 커널에 TCP 연결 개설을 요청하고, 커널은 특별한 권한 없이 핸드셰이크를 수행합니다. 원시 스캔은 패킷을 직접 만들며, 플랫폼에 따라 원시 소켓이나 캐처 드라이버가 필요합니다. 이는 권한과 드라이버의 문제이며, VPN 연결 여부와 관계없이 존재합니다.
이 차이가 흔한 비대칭을 설명합니다. curl 는 소켓 경로가 작동하므로 성공하고, SYN 스캔은 프로세스가 터널 인터페이스에서 원시 소켓을 열 수 없으므로 실패합니다. 반대 경우도 설명하는데, 경로가 프로브를 버리므로 원시 스캔은 필터링됨으로 보고하지만 애플리케이션 경로는 정상으로 남습니다.
두 결과 중 어느 것도 원격 서비스를 설명하지 않습니다. 둘 다 한 방법 아래의 한 경로를 설명하므로, 방법을 결론에 붙여 두십시오.
승인된 호스트 하나에서 연결 확인을 실행하십시오
작업 범위에 있는 단일 호스트를 고르고, 원시 접근이 필요 없는 모드를 사용하십시오. 여기서 예시 대상은 198.51.100.24 이며, 이런 유형의 예시를 위해 예약된 문서용 주소입니다.
한 줄, 한 호스트, 한 포트, 탐색 단계 없음:
nmap -sT -Pn -p 443 --unprivileged 198.51.100.24-sT 는 완전한 TCP 연결을 선택하므로 애플리케이션이 쓰는 것과 같은 커널 경로를 사용하고 캐처 드라이버가 필요 없습니다. -Pn 는 호스트 탐색을 생략하지만, nmap은 로컬 세그먼트의 대상에 대해 링크 계층 해석을 수행하므로, 이 플래그가 사전 트래픽이 전혀 없다는 약속은 아닙니다. --unprivileged 는 원시 또는 스니핑 권한이 없다고 가정하라고 nmap에 알리며, 이는 방법을 바꾸는 덧 아무것도 부여하지 않습니다.
각 플래그를 하나의 변경으로 읽고, 수리로 읽지 마십시오
모든 옵션을 방법에 대한 진술로 다루십시오. -sT, -Pn, --unprivileged 중 어느 것도 경로를 추가하지 않고, 원격 방화벽을 열지 않으며, 인증서를 검증하지 않습니다. 연결 스캔은 서비스가 기록하는 실제 핸드셰이크도 완료하므로, 승인된 점검과 승인되지 않은 훡기가 서버 측에서 범위와 속도를 제외하고는 같아 보입니다. 출력이 바뀜일 때까지 옵션을 쌓는 것은 방법 문제를 네트워크 소견으로 기록하는 방식입니다.
출력이 닫힌을 말하면 무언가가 리셋으로 응답한 것이며, 이는 침묵과는 다른 소견입니다. 출력이 필터링됨을 말하면 장치가 프로브나 그 응답을 버렸으며, VPN은 부수적일 수 있습니다. 정확한 문구를 기록하십시오, 탐색 단계의 판정과 프로브 수준의 실패는 서로 다른 계층을 가리키기 때문입니다.
권한 있는 모드가 정말 필요하다면, 권한과 드라이버, 인터페이스 배열이 지원되는지 플랫폼 소유자가 결정합니다. 같은 호출을 승격해도 방법은 바뀜지 않습니다.
전송 결과에서 멈추고, 그다음에 서비스를 시험하십시오
완료된 핸드셰이크는 하나의 주소, 포트, 출발지, 시점에 관한 한 가지 질문에 답합니다. 로드 밸런서나 전면 프록시가 연결을 받아들이는 동안 그 뒤의 애플리케이션이 멈춰 있을 수 있으므로 백엔드가 건강하다는 증거는 아닙니다.
이어서 서비스 자체의 클라이언트로 TLS 신원과 애플리케이션 동작을 별개의 사실로 관찰하십시오:
openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health한 가지 습관이 결과를 쓸모 있게 유지합니다. 정확한 명령, 사용한 출발지 주소, 시각을 기록하십시오, 그 맥락이 없으면 전송 결과를 재현하거나 비교할 수 없기 때문입니다.
인증서가 예상하지 못한 호스트를 가리키면 전송은 작동했고 라우팅은 문제가 아니었고, 결함은 가상 호스팅이나 DNS에 있습니다. 핸드셰이크가 실패하면 터널에 대해 일반화하지 말고 로컬 오류 문자열을 기록하십시오. 범위 메모를 결과 옆에 두십시오, 다음 사람이 어느 방법으로 얻은 결과인지 알아야 하기 때문입니다.