IPsec ESP: 무엇을 나르며 흐르고 있음을 어떻게 증명할까
ESP는 터널 모드에서 내부 IP 패킷을 감싸고 SPI로 그 연관을 식별합니다. 상태를 읽고, 이어서 하나의 흐름이 카운터를 움직이는지 확인하십시오.
ESP는 IPsec VPN에서 트래픽을 나르며, 그 runbook은 한 가지 규칙, 즉 정책을 바꾸기 전에 보안 연관을 읽는 것에서 시작한다. 설명되지 않는 ESP 동작의 대부분은 일치하지 않은 선택자, 읽지 않고 가정한 모드, 또는 하나의 흐름을 보내는 동안 아무도 확인하지 않은 카운터로 되돌아간다. 아래 세 단계는 무엇이 무엇을 나르는지 확정하고, 하나의 흐름이 그것을 사용함을 증명하며, 기억에 의존하지 않는 되돌리기를 남긴다. 각 단계는 기록할 가치가 있는 관찰을 하나씩 만든다.
읽기 전에 필드를 알아 두십시오
ESP는 보호되는 데이터 앞에 헤더를, 뒤에 트레일러를 둔다. 헤더는 수신 측이 어느 연관을 사용해야 하는지 식별하는 보안 매개변수 색인, 재생을 감지하기 위한 순서 번호를 나르고, 트레일러에는 암호를 위해 페이로드를 정렬해 유지하는 패딩이 들어간다. 트레일러의 다음 헤더 필드는 보호된 내용이 무엇인지 알려 주며, 그것으로 수신 측은 무엇을 역캡슐화했는지 안다.
모드는 그 보호 안에 무엇이 들어가는지를 바꾼다. 터널 모드에서는 보호되는 것이 완전한 내부 IP 패킷이고, 새 외부 헤더가 두 끝점 사이에서 그것을 나른다. 전송 모드에서는 보호가 기존 패킷의 상위 계층 페이로드를 감싸므로 열어야 할 두 번째 IP 헤더가 없다. 어떤 모드를 쓰는지는 구성의 사실이지 해석의 문제가 아니다. 다이어그램에서 추론하지 말고 상태 항목에서 읽으십시오.
어느 모드도 패킷을 전달해야 하는 외부 주소 지정을 숨기지 않는다. 그것은 설계의 성질이지 결함이 아니며, 그래서 페이로드가 불투명해도 중간 관찰자는 어떤 두 주소가 이야기하는지 여전히 볼 수 있다.
첫 단계: 상태를 읽고, 그다음 정책
상태 항목은 키와 카운터를 담고, 정책 항목은 누가 그것을 사용할 수 있는지 정하는 선택자를 담는다. Linux에서는 둘 다 패킷 캡처 없이 보이며, 그 순서로 읽으면 두 질문이 분리된 채로 남는다.
ip xfrm state
ip xfrm policy
상태 출력에서 연관의 원본과 목적지, 모드, 그리고 캡슐화가 UDP 포트를 보여 주는지 확인하십시오. 그 포트는 NAT 통과가 사용 중임을 뜻한다, 이는 중간 방화벽이 무엇을 허용해야 하는지를 바꾸지만, 끝점에서 어떤 선택자나 키가 적용되는지는 바꾸지 않는다.
그다음 정책의 선택자를 읽으십시오. 시험하는 트래픽보다 좁은 접두사를 지정하는 선택자는 작동하는 터널이 흐름을 무시하는 것처럼 보이는 가장 흔한 이유이며, 잘못된 프로토콜의 선택자도 같은 침묵을 만든다.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
공급업체 도구는 같은 정보를 더 편한 형태로 출력한다. ipsec statusall strongSwan에서는 자식 연관, 그 선택자, 바이트 카운터를 나열하는데, 어느 자식을 볼지 이미 알고 있다면 원시 xfrm 출력을 읽는 것보다 흔히 더 빠르다.
둘째 단계: 하나의 흐름이 카운터를 움직임을 증명하십시오
카운터는 무엇이 그것을 움직였어야 하는지 알 때만 의미가 있다. 그러니 선택자가 확실히 포괄하는 원본과 목적지를 골라 무해한 요청 하나를 보내고, 그다음 같은 항목을 다시 읽고 비교하십시오.
ip -s xfrm state
tcpdump -ni any esp
두 번의 읽기는 다른 이야기를 한다. 나가는 쪽에서는 늘지만 들어오는 쪽에서는 결코 늘지 않는 패킷은, 캡슐화되어 떠났으므로 키 문제가 아니라 전달이나 귀환 경로 문제를 가리킨다. 어떤 카운터도 움직이지 않는다면 트래픽은 정책과 한 번도 일치하지 않은 것이다, 그리고 볼 곳은 선택자다.
같은 단계의 캡처는 외부 패킷이 ESP인지 UDP로 캡슐화된 ESP인지를 포함해 회선 위의 캡슐화를 확인해 준다. 또한 흐름을 실제로 나른 주소를 보여 주는데, 그것은 읽고 있던 구성의 주소와 다를 때가 있다.
셋째 단계: 한 가지만 바꾸고 되돌리기를 남기십시오
무엇이든 편집하기 전에 연관의 원본, 목적지, 모드, 선택자, 카운터를 기록하십시오. 변경이 상황을 나쁘게 만들면 그 기록이 있어야 추측으로 동작하는 구성을 다시 만드는 대신 이전 상태를 복원할 수 있다. 그 기록은 쓰는 데 일 분이 걸리고 나중에 한 시간을 아낀다. 그것은 변경을 한 사람 이후에도 남는 유일한 산출물이기도 하다.
선택자 하나나 매개변수 하나를 바꾸고, 다시 로드하고, 같은 흐름에 대해 둘째 단계를 반복하십시오. 연관을 삭제하면 그것을 쓰는 모든 흐름이 무너지므로, 표적 편집과 자식 다시 로드가 무슨 일이 일어나는지 보려고 상태를 비우는 것보다 거의 항상 낫다.
선택자 편집의 되돌리기는 이전 정책을 복원하고 다시 로드하는 것이며, 선택자가 로컬이 아니라 협상되는 경우 상대에게 대응하는 변경이 필요할 수 있다는 단서가 붙는다. 그 의존은 신선할 때 적어 두십시오, 반쯤 복원된 쌍은 두 최종 상태 어느 쪽보다 생각하기 어렵기 때문이다.
마지막으로 범위를 정직하게 유지하십시오. 흐르는 ESP 연관은 두 게이트웨이가 세그먼트를 보호하고 전달함을 증명하지만, 그 위의 애플리케이션이 사용자를 인증하는지, 저장하는 것을 암호화하는지에 대해서는 아무 말도 하지 않는다. 그것들은 별도의 증거를 가진 별도의 통제이며, runbook은 다음 사람이 기록에서 그것을 반복할 수 있을 때에만 끝난다.