작동하는 IPsec 게이트웨이에서 ike-scan이 응답을 받지 못함
호스트가 응답하지 않았다는 것은 보통 제안 불일치이며 VPN 누락이 아닙니다. 기본 변환 집합을 읽고 현대적인 제안을 보내며 침묵을 신중히 해석하세요.
그 게이트웨이는 매일 휴대폰과 노트북에 서비스를 제공하지만, ike-scan은 어떤 호스트도 응답하지 않았다고 보고합니다. 이 출력은 기기에 IPsec이 없다는 증거처럼 읽힙니다. 보통은 기기가 프로브의 모든 제안을 버리고 아무것도 응답하지 않기로 선택했다는 뜻입니다. 침묵도 응답이며, 도구가 줄 수 있는 가장 정보가 적은 응답입니다.
패킷이 도착했는지, 어떤 제안이 일치했는지, 다른 무언가가 피어를 거부했는지라는 세 가지 별개의 질문을 차례로 확인하세요.
1단계: 도구가 보내는 제안 읽기
주 모드는 개시자가 수락할 변환을 나열하는 SA 페이로드로 시작하며, ike-scan은 컴파일된 기본값에서 그 목록을 채웁니다. 기본 집합은 의도적으로 오래되었는데, 암호화에는 DES와 3DES, 해싱에는 MD5와 SHA1, 키 교환에는 그룹 1과 2, 인증에는 사전 공유 키를 사용합니다. AES도 없고 SHA-2도 없고 그룹 14도 없습니다. AES-256, SHA-256, modp2048로 구성된 게이트웨이와는 공통점이 없습니다.
일부 구현은 일치하지 않는 프로브에 NO-PROPOSAL-CHOSEN 알림으로 응답합니다. 다른 구현은 그냥 버리는데, 알 수 없는 피어를 잡음으로 취급하는 장비에서 흔합니다. 어느 쪽이든 스캔은 아무것도 출력하지 않으며, 그 ‘아무것도’는 외부에서 본 필터링된 UDP 500과 똑같으며, ike-scan 프로젝트 문서가 기본 집합에 대해 분명히 밝히는 대로입니다.
2단계: 현대적인 제안 하나 보내기
기본 집합을 --trans로 바꾸세요. 속성 형식은 IKE 속성 번호를 직접 받는데, 암호화에는 1, 해시에는 2, 인증에는 3, 그룹에는 4, 알고리즘이 키 길이를 받는 경우에는 14입니다. 나오는 것은 변경 검토에서 소리 내어 읽을 수 있는 한 줄입니다.
위치 형식은 같은 값을 순서대로 담고 괄호를 피하는데, 이는 명령이 셸을 거칠 때 중요합니다.
ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10
열거할 때 패킷당 하나의 제안은 느리므로 그럴듯한 값들을 반복하세요. 암호화 5, 7/128, 7/192, 7/256, 해시 1, 2, 5, 6, 7, 그룹 1, 2, 5, 14, 15, 19, 20, 21, 인증은 사전 공유 키에 1, RSA 서명에 3이며, 각 명령을 실행하기 전에 출력하여 기록이 무엇이 어떤 순서로 제안되었는지 보여 주게 하세요.
3단계: 응답 해석하기
응답은 정확히 두 가지, 즉 그 주소에서 IKE 응답자에 도달할 수 있다는 것과 제안한 하나가 수락 가능했다는 것을 증명합니다. 사전 공유 키, L2TP 계층, 사용자 계정의 존재 여부에 대해서는 아무것도 말하지 않습니다. 성공한 스캔은 이후 모든 단계의 실패와 완전히 양립합니다.
운영하는 게이트웨이에서 이것이 정말 유용한 부분입니다. 스캔은 기기가 여전히 수락하는 제안을 알려 주고, 레거시 변환으로 제한된 결과는 기기 정책에 관한 발견이며 클라이언트를 약화할 이유가 아닙니다.
4단계: 침묵 해석하기
침묵은 보기보다 약한 증거입니다. 모든 제안이 거부되었을 수 있고, UDP 500과 4500이 필터링되었을 수 있으며, 버스트 후 소스가 속도 제한되었을 수 있고, 서비스가 스캔한 주소와 다른 주소에서 수신 대기 중일 수도 있습니다. 그 상자에 대해 어떤 결론을 내리기 전에 게이트웨이의 IKE 로그를 유효한 자격 증명으로 이미 연결된 클라이언트와 비교하세요.
버스트 동작도 그 목록에 포함됩니다. 열거는 짧은 시간 창에서 많은 패킷을 만들기 때문인데, 처음 몇 번의 시도에 응답한 뒤 조용해지는 게이트웨이는 제안 집합이 아니라 anti-DoS 정책을 설명하는 것입니다.
5단계: 증명한 것을 기록하기
수락된 조합을 펌웨어 버전 옆에 적고, 관심 있는 클라이언트가 기본적으로 제공하는 변환과 비교하세요. 그 두 목록 사이의 격차가 구성 문제이며, 스캔은 그것을 눈에 보이게 했을 뿐입니다. 수락되는 제안이 선택하지 않을 것뿐이라면 수정은 게이트웨이 정책이나 클라이언트 프로필에 속하며, 프로브에는 절대 속하지 않습니다.
결코 응답하지 않은 프로브도 이 기기가 어떤 제안을 논의할 의사가 있고 어떤 것을 차라리 바닥에 버릴지 보여 준다는 점에서 무언가에는 응답했습니다.