IKEv2가 TS_UNACCEPTABLE을 반환하면 실제 서브넷을 비교하십시오

TS_UNACCEPTABLE은 손상된 프로필이 아니라 커버리지 불일치로 읽어야 합니다. 게이트웨이는 두 피어가 이 터널이 어떤 주소를 실을 수 있는지 합의하지 못했다고 말하는 것입니다. 그 시점에 IKE SA는 이미 올라와 있을 수 있으므로, 클라이언트는 뒤에 자식 SA가 없는데도 연결된 것처럼 보일 수 있습니다. 이렇게 틀을 잡으면 작업은 기계적으로 변합니다. 양쪽의 의도한 접두사를 적고, 한 방향으로 비교하고, 교차할 때까지 좁히십시오.

먼저 의도한 쌍을 적으십시오

설정을 건드리기 전에 시작 측의 출발지 범위, 그 목적지 범위, 그리고 응답 측에서 본 같은 쌍이라는 네 개의 값을 나열하십시오. 각각의 주소 체계도 기록하십시오. IPv4 범위와 IPv6 범위는 서로 다른 선택자 유형이며, 어느 쪽도 상대의 페이로드에 접을 수 없습니다.

정책이 지니는 모든 프로토콜 또는 포트 제한을 추가하십시오. 파일 서버로 가는 TCP 445만 허용하는 규칙은 그것이 속한 서브넷보다 좁은 집합을 나타냅니다. 이것을 메모에서 빼면 협상 결과는 보이지 않는 이유로 일관성이 없어 보일 것입니다.

비교 전에 레이블을 뒤집으십시오

로컬과 원격은 상대적인 표시입니다. 클라이언트의 로컬 접두사는 게이트웨이의 원격 범위이고, 게이트웨이의 로컬 범위는 클라이언트의 원격입니다. 그래서 양 끝의 스크린샷은 결코 맞아떨어지지 않으며, 그것을 문자 그대로 비교하는 것이 오후를 날리는 흔한 방법입니다.

응답 측은 제안을 거부하는 대신 받아들일 수 있는 부분집합으로 좁힐 수 있습니다. 그 결과는 절반만 동작하기 때문에 깔끔한 실패보다 나쁩니다. 정책이 10.0.5.0/24를 허용할 때 10.0.0.0/16을 요청하면 그 /24만 덮는 자식 SA로 끝날 수 있습니다. 호스트 하나만 응답하고 나머지는 모두 밖으로 떨어지며, 클라이언트에서는 아무것도 그것을 알려주지 않습니다. 협상이 성공했다고 결론 내리기 전에 요청한 선택자가 아니라 수락된 선택자를 읽으십시오.

기본 경로를 요청하는 로드워리어 프로필은 여기에 끊임없이 떨어집니다. 분할 액세스용으로 만들어진 게이트웨이는 전체 범위 제안을 자기 서브넷으로 좁히고, 클라이언트는 좁혀진 결과를 받아들이거나 크게 실패해야 합니다.

거부는 한 번의 시도에서 읽으십시오

같은 연결 시도의 두 로그를 모두 모으십시오. 저장된 프로필은 설정한 내용을 보여줄 뿐 제안된 내용이 아니며, strongSwan에서는 swanctl --log가 수신한 알림을 그것이 실은 선택자와 함께 출력합니다.

그다음 실제로 무엇이 설치되었는지 확인하십시오. swanctl --list-sas는 자식 SA의 선택자를 보여주고, ip xfrm policy는 같은 범위를 커널 정책 항목으로 보여줍니다. 그 목록에서 의도하지 않은 선택자를 가진 자식 SA가 있다면 좁힘 사건이고, 자식 SA가 없는데 로그에 TS_UNACCEPTABLE이 있다면 거부입니다.

그곳에 있는 동안 가까운 이웃들을 분리하십시오. INVALID_SELECTORS는 이미 성립된 자식 SA 내부의 선택자에 대해 불평하고, INTERNAL_ADDRESS_FAILURE는 응답 측이 가상 주소를 할당하지 못했다는 뜻이며, 이는 커버리지가 아니라 풀 문제입니다.

무엇이 조용히 집합을 줄이는지 확인하십시오

세 가지가 아무 말 없이 선택자 집합을 줄입니다. 첫째는 응답 측 정책으로, 서브넷 목록, 그룹 규칙, 사용자별 권한을 통해 제안이 부분집합으로 줄어듭니다. 둘째는 주소 체계로, 이중 스택 클라이언트는 흔히 IPv4와 함께 IPv6를 제안하고, 게이트웨이가 한 번도 설정하지 않은 범위에 대해 거부를 받습니다.

셋째는 프로토콜과 포트 제한입니다. 정책이 TCP 445만 허용하는 곳에서는 ICMP와 UDP가 밖에 남은 채 자식 SA가 올라올 수 있고, 사용자는 허용된 것이 프로토콜 하나뿐이었는데도 터널이 끊겼다고 보고합니다.

따라서 주소를 넓히는 것만으로는 포트로 제한된 정책을 고칠 수 없으며, 바로 이 경우가 세 차례의 문제 해결을 거치고도 변하지 않고 남을 가능성이 가장 큽니다.

맞는 트래픽으로 커버리지를 증명하십시오

자식 SA가 설치된 뒤, 수락된 범위 안에 확실히 들어가는 요청을 하나 보내십시오. 상태 아이콘이 아니라 ip -s xfrm state와 ip xfrm policy 뒤의 카운터가 패킷이 일치하고 보호될 때 증가하는 것을 보십시오. 실제 트래픽 후에도 영에 머무는 바이트 수는 커널이 그 정책을 한 번도 선택하지 않았다는 뜻입니다.

그 영은 라우팅 또는 정책 순서 문제이지 암호 문제가 아닙니다. 사용자 입장에서는 선택자 거부와 똑같이 보이므로, 프로필을 다시 열기 전에 카운터를 모을 가치가 있습니다. 한 방향으로만 증가하는 카운터는 대신 반환 경로를 가리킵니다.

마지막으로 수락된 쌍을 처음 요청한 범위 옆에 티켓에 적으십시오. 선택은 요구만큼 좁게 유지해야 하는데, 사설 범위를 모든 주소로 바꿔 오류를 없애면 계정에 승인된 것보다 훨씬 많은 접근을 허용하게 되기 때문입니다.