IPsec 프로필의 다섯 가지 주소 역할, 그리고 어느 것이 틀렸나
엔드포인트, ID, 보호 서브넷, 게이트웨이 소스, 다음 홉은 각각 다른 질문에 답합니다. 먼저 증상을 필드에 맞추십시오.
일반적인 연결 정의에서 다섯 가지 서로 다른 작업이 주소를 받으며, 그것들이 서로 일치할 필요는 없습니다. 관리자가 막히는 이유는 모든 필드를 같은 호스트로 향하게 하라는 그럴듯한 직관이 적어도 세 가지에는 틀렸기 때문입니다. 출구는 먼저 증상을 이름 붙이고, 그다음 그것을 만들어 낼 수 있는 한두 개의 필드를 보는 것입니다.
다섯 가지 작업, 중요한 순서대로
전송 엔드포인트는 IKE 교환이 전달되는 지점입니다.인증된 ID는 각 측이 증명하는 이름이며, 라우팅 테이블이 아니라 정책에 대해 검사됩니다. 보호 서브넷은 어떤 내부 트래픽이 터널에 속하는지 결정하는 선택자입니다. 그다음 게이트웨이 자체가 대화를 시작할 때 쓰는 소스가 있고, 마지막으로 피어에 도달하기 위한 언더레이의 다음 홉이 있습니다.
left 와 right 같은 참가자 레이블은 연결의 두 측을 위한 관례일 뿐, 로컬과 원격의 동의어가 아닙니다. 어떤 키가 다른 제품에서 뜻했던 것을 그대로 뜻한다고 가정하기 전에 실제로 설치된 구현의 설명서를 읽으십시오.
| Job | Typical key | What fails when it is wrong |
|---|---|---|
| Transport endpoint | left, right | No IKE exchange at all |
| Authenticated identity | leftid, rightid | Exchange starts, peer rejects it |
| Protected subnets | leftsubnet, rightsubnet | Tunnel up, traffic not selected |
| Gateway source | leftsourceip, rightsourceip | Only gateway-originated flows fail |
| Underlay next hop | leftnexthop, rightnexthop | Peer unreachable from this host only |
판단 하나: 아무것도 성립하지 않는다
로그에 교환이 전혀 나타나지 않으면 엔드포인트가 첫 용의자입니다. 잘못된 주소, 필터된 경로, 또는 데몬이 수신하지 않는 인터페이스입니다. 핸드셰이크가 보인 뒤에야 ID 필드로 넘어가십시오. ID는 교환 내부에서 판정되며 그 이전이 아니기 때문입니다. 필터된 경로와 잘못된 주소는 클라이언트 쪽에서 똑같이 보이므로, 무엇이든 편집하기 전에 수신하는 쪽을 확인하십시오. 데몬이 예상한 인터페이스에 바인딩되어 있는지 확인하십시오. 한 주소에서 수신하는 서비스는 차단된 경로와 정확히 똑같이 보입니다.
변환을 거쳐 관찰된 공인 주소는 피어가 증명하는 ID와 같은 것이 아닙니다. 원격 끝에서 패킷 캡처가 보여 주는 것에 맞추어 주소를 바꾸는 것은 흔하고 잘못된 수정입니다.
판단 둘: 터널은 올라가 있는데 트래픽이 죽는다
선택자는 터널에 무엇이 들어가는지 결정하며, 여기서 어긋나면 협상은 성공하지만 애플리케이션은 계속 실패하는 연결이 생깁니다. 원격 측은 당신의 보호 범위를 자신의 원격 범위로 지정해야 하며, 바로 그 지점에서 뒤집힌 값이 스며듭니다.
편집하기 전에 두 구성을 나란히 읽으십시오. 한 호스트의 로컬 범위는 다른 호스트의 원격 범위이며, 한 쌍만 뒤바뀌어도 아무것도 나르지 않는 터널이 설명됩니다. 키를 건드리기 전에 쌍을 좁히십시오. 터널 안쪽에 하나, 바깥쪽에 하나의 서브넷을 두면 선택자와 라우팅 중 무엇이 문제인지 알 수 있습니다.
판단 셋: 게이트웨이 자체의 트래픽만 실패한다
클라이언트를 위해 전달되는 트래픽은 완벽하게 동작하는데, 게이트웨이가 스스로 시작한 요청은 실패할 수 있습니다. 그 흐름에는 물려받을 클라이언트 소스가 없기 때문입니다. 기본 소스 설정은 바로 이 경우를 위한 것이며 소스 변환이 아닙니다. 다시 쓰는 대신 소스 주소를 고르는 것입니다.
다른 주소를 명시적으로 바인딩하는 애플리케이션은 그 기본 설정을 덮어쓸 수 있으므로, 설정이 무시된다고 결론 내리기 전에 패킷의 실제 소스를 확인하십시오. 구성의 의도를 믿는 대신 게이트웨이 자체 인터페이스에서 캡처하십시오.
다음 홉은 로컬 지시다
언더레이의 다음 홉은 이 호스트에게 피어에 도달하는 방법을 알려 주며, 원격 측에는 같은 값이 필요하지 않습니다. 이것을 공유 설정으로 다루거나 기본 게이트웨이를 하드코딩하면 경로가 바뀌거나 두 번째 길이 나타나는 순간 깨집니다.
일부 구현은 여기에 특별한 값을 제공합니다. 설치된 버전에 대해 설명서가 나열하는 것이 유일하게 안전한 답이며, 로컬 라우팅 테이블이 그것이 동작했다는 증거입니다. 피어에 이름으로는 닿지만 주소로는 닿지 않을 때, 그 불일치가 바로 발견이며 피해 갈 세부 사항이 아닙니다.
프로필을 양쪽 끝에서 읽으십시오
종이 위에서 역할을 뒤집는 것이 가장 빠른 검토입니다. 보호 범위를 맞바꾸고, 각 측의 다음 홉과 각 측의 ID를 유지하십시오. 맞바꿈을 견디지 못하는 것은 아마도 잘못된 작업에 배정된 것입니다.
그다음 역할마다 하나의 흐름을 시험하십시오. 피어 간 도달성, 내부 클라이언트 흐름, 게이트웨이에서 시작된 요청입니다. 세 가지 시험이 구성을 다시 열지 않고 어느 작업이 잘못 배정되었는지 알려 줍니다. 결과를 변경한 필드 옆에 티켓에 적어 두십시오. 다음 엔지니어가 같은 프로필을 만나게 됩니다.