Android VPN에서 Cisco IOS로: 먼저 받아야 할 계약

휴대폰이 Cisco 게이트웨이에 닿아야 한다. 설치할 클라이언트는 이미 누군가 정해 두었다. 그것은 절차의 잘못된 끝이며, 한 시간 동안 자격 증명을 다시 입력한 끝에 터널이 실패하는 이유다.

먼저 필요한 것은 연결 계약이다. 프로토콜, 인증, 신원, 신뢰 자료, 주소 할당, 라우팅을 게이트웨이 운영자가 문서로 남겨야 한다.

그것을 문서로 받으면 클라이언트 선택은 조회가 된다. 빠뜨리면 모든 실패가 잘못된 비밀번호처럼 보인다.

무엇이든 설치하기 전에 사전 조사를 하라

게이트웨이 소유자에게 목록을 보내고 제품 이름이 아니라 답을 요구하라. 아홉 항목이 원격 접속 프로파일을 완전히 덮는다.

1. 클라이언트가 연결할 게이트웨이의 호스트 이름 또는 주소, 그리고 외부에서 닿을 수 있는지.
2. 프로토콜과 버전. IKEv2인지, 다른 세대의 IPsec인지, TLS 기반 서비스인지.
3. 게이트웨이가 기대하는 상대 신원과 게이트웨이 자신이 제시하는 것.
4. 신뢰 자료. 게이트웨이 인증서에 서명하는 CA가 무엇인지, 사전 공유 키를 쓰는지.
5. 사용자 인증. 인증서인지, EAP 사용자 이름과 비밀번호인지, 사전 공유 키인지.
6. 클라이언트가 들어갈 주소 풀과 그 마스크, 게이트웨이.
7. 터널 안에서 쓸 DNS 서버와 클라이언트가 이를 받아들여야 하는지.
8. 허용된 목적지 프리픽스와 그 바깥 트래픽을 차단해야 하는지.
9. 지원되는 클라이언트 버전과 휴대폰 OS 버전, 그리고 등록 요건이 있으면 그 내용.

이 가운데 두 항목이 피할 수 있었던 실패의 대부분을 만든다. 신뢰 자료가 없으면 게이트웨이를 검증할 수 없어 올바른 클라이언트도 고장 난 것처럼 보인다. 허용된 프리픽스가 없으면 라우팅 제한과 서비스 문제를 구분할 수 없다.

공급자 이름은 프로토콜이 아니다

Cisco IOS와 IOS XE는 원격 접속 방식을 여러 가지 제공하며 전송 형식을 공유하지 않는다. FlexVPN 스타일 프로파일을 쓰는 IKEv2는 예전 IKEv1 구성과 같은 서비스가 아니고, TLS 기반 클라이언트 서비스는 또 다른 제품이며 흔히 같은 환경의 다른 플랫폼에 있다.

따라서 이름에 라우터 공급자가 들어간 클라이언트는 아무것도 증명하지 않는다. 그중 한 서비스를 잘 구현했을 뿐 나머지는 아닐 수 있다. 어떤 서비스가 구성되어 있는지 묻고, 그다음 클라이언트 문서가 그 서비스를 지원한다고 적는지 확인하라.

Cisco 자체의 IKEv2 문서는 제안, 정책, 프로파일, 키링을 별개의 객체로 나눈다. 이 구조는 누군가 붙여 넣은 구성을 읽을 때 유용하다. 파일 전체를 한 덩어리로 보는 대신, 원격 휴대폰에 중요한 설정이 어느 객체에 있는지 알려 준다.

Android 기본 스택이 담당하는 범위

Android는 Ikev2VpnProfile을 통해 플랫폼 IKEv2/IPsec 프로파일을 노출하며, 사전 공유 키, RSA 인증서, EAP 사용자 이름과 비밀번호에 대해 인증 유형이 나뉜다. Ikev2VpnProfile 참조가 빌더가 무엇을 받아들이는지에 대한 기준이며, 게이트웨이 호스트 이름과 이를 검증하는 데 쓰는 서버 루트 CA도 포함된다.

그 API는 능력 선언이지 호환성 약속이 아니다. 그 인증 유형으로 IKEv2를 할 수 있다는 뜻일 뿐이다. 특정 OEM 설정 화면이 모든 항목을 노출한다거나 다른 제품에서 내보낸 프로파일 파일이 가져와진다고 말하지 않는다.

따라서 게이트웨이가 플랫폼이 구현하지 않은 서비스를 돌린다면 기본 스택으로는 해결되지 않는다. 그때는 운영자가 지원하는 공급자 클라이언트를 운영자 문서대로 설치하고 구성해야 한다. 휴대폰이 말하지 않는 프로토콜로 우회해서는 안 된다.

계약에 적힌 순서대로 시험하라

한 번에 한 계층만 검증하고 첫 실패에서 멈춰라. 앞 계층이 통과되지 않으면 뒤 시험은 의미가 없다.

신뢰. 클라이언트가 게이트웨이 인증서를 거부하면 나머지는 문제가 아니다. 받은 CA가 게이트웨이가 제시하는 인증서에 서명하는지, 접속한 호스트 이름이 그 안에 있는지 확인하라. 검증은 끄지 마라. 끄면 신원 문제가 도청 위험으로 바뀐다.

인증. 자격 증명 거부와 제안 불일치는 다른 오류지만 비슷한 실패로 보인다. 게이트웨이 로그가 판별자다. 사용자에 대해 말하기 전에 제안이 받아들여질 수 있었는지를 알려 준다.

주소와 DNS. 휴대폰이 문서화된 풀에서 주소를 받았는지 확인하고, 다음에 내부 이름 하나를 해석하라. 주소는 받았지만 리졸버가 없는 터널은 연결된 것처럼 보이면서 아무것도 되지 않는 것처럼 행동한다.

도달성. 허용된 목적지 하나를 주소로 시험하고 다음에 이름으로 시험하라. 주소는 되고 이름이 안 되면 DNS로 돌아온 것이다. 둘 다 안 되면 클라이언트를 건드리기 전에 시험 중인 프리픽스를 허용 목록과 대조하라.

실패 유형과 롤백

무엇이든 바꾸기 전에 이전에 작동하던 프로파일을 내보내고 문서화해 두어라. CA 별칭과 주소 풀도 포함한다. 그러면 롤백은 알려진 프로파일을 복원하는 일이지, 장애 중에 기억으로 다시 만드는 일이 아니다.

작동하면 사전 조사의 아홉 답을 프로파일 옆에 기록하라. 다음 휴대폰, 다음 OS 업데이트, 다음 게이트웨이 변경이 모두 추측의 오후가 아니라 문서와의 비교가 된다.