두 IPsec 피어 사이의 라우터에 IPsec이 필요한가?

“두 사이트 사이에 IPsec을 구성하라”는 실습 과제는 서로 다른 두 작업을 숨깁니다. 두 끝단이 터널을 종료하며 협상하고 인증하고 암호화하고 복호화합니다. 중간의 어느 라우터든 외부 헤더가 끝단에 속한 패킷을 전달하며, 터널이 존재한다는 사실조차 모른 채 그렇게 합니다.

장비에 어떤 작업이 요구되는지 판단하는 것이 실습의 첫 단계입니다. 실습 보고서의 혼란 대부분과 운영 다이어그램의 상당 부분은 “IPsec을 지원한다”를 두 가지가 아닌 한 가지 속성으로 다루는 데서 비롯됩니다.

전달은 종료가 아닙니다

터널 모드에서 외부 IP 헤더는 터널을 종료하는 장비로 지정됩니다. 중간의 라우터는 목적지를 조회해 전달하며, 다른 어떤 패킷과도 똑같이 처리하고, 라우터가 나르는 페이로드는 라우터에게 불투명합니다.

이 불투명성은 의도된 것입니다. 라우터는 상대의 비밀을 보관하지 않고, 협상을 수행하지 않으며, 정책 데이터베이스도 필요로 하지 않습니다. 필요한 것은 원격 끝단으로 가는 경로와 패킷을 전달할 권한뿐입니다.

둘을 혼동하면 실제 요구가 특정 주소 사이에서 프로토콜 50을 허용하는 것인데 통과 방화벽에 “IPsec 허용”을 요청하거나, 키도 없으면서 중간 장비가 검사를 위해 복호화할 것이라고 기대하는 식의 실제 오류가 생깁니다.

중간 장비가 그래도 올바르게 해야 할 일

전달에는 고유한 요구 사항이 있습니다.경로는 두 외부 끝단에 도달해야 합니다, 경로상의 모든 정책은 추측한 포트 번호가 아니라 실제 외부 트래픽을 허용해야 합니다. 누군가 TLS를 가정한 탓에 TCP 443에 맞춰 작성된 규칙은 프로토콜 50과 일치하지 않습니다.

기본 ESP는 IP 프로토콜 50입니다. TCP 50도 UDP 50도 아니며, 비TCP 트래픽을 막는 규칙은 이를 버립니다. 설계가 UDP 캡슐화를 사용하면 보이는 전송은 캡슐화 포트로 바뀌고, 정책은 선택한 설계와 일치해야 합니다.

패킷 크기도 중요합니다. 작은 프로브를 통과시키는 경로는 캡슐화된 전체 교환이 들어간다는 증거가 아닙니다. 큰 패킷을 버리는 경로는 협상은 성공하고 워크로드는 실패하게 만들 수 있으며, 이는 애플리케이션 문제처럼 보입니다. 터널을 탓하기 전에 실제 워크로드 크기의 트래픽으로 시험하십시오.

시뮬레이터가 질문을 바꾸는 이유

시뮬레이터는 기능 목록이 짧은 라우터가 아니라, 문서화된 부분 집합과 특정 장비로 무엇을 하도록 구성할 수 있는지에 관한 자체 규칙을 가진 모델입니다. Cisco의 Packet Tracer FAQ는 장비와 프로토콜이 단순화된 모델이라고 분명히 밝힙니다.

그래서 질문은 세 가지가 됩니다. 시뮬레이션된 장비가 시나리오에 필요한 패킷을 전달하는가? 같은 장비가 수업이 전제하는 구성 표면을 제공하는가? 그리고 수용된 명령이 동작이 실제로 시뮬레이션된다는 뜻인가, 아니면 구문만 분석된다는 뜻인가?

없는 명령은 구성의 오류가 아니라 모델의 한계일 수 있습니다. 있는 명령은 모든 생산 동작을 재현하지 않은 채 구문만 받아들일 수 있습니다. 어느 쪽으로 결론 내리기 전에 설치된 버전의 장비 도움말을 확인하십시오.

실습의 통과 조건 작성하기

언더레이 수업에서는 통과 조건이 끝단 도달성과 중간 장비를 지나는 외부 패킷입니다. 시뮬레이터 자체의 카운터나 패킷 보기로 증명하고, 기대하는 프로토콜을 지목하십시오.

IPsec 수업에서는 협상 상태와 보호된 LAN 대 LAN 흐름 하나를 추가합니다. 시뮬레이터가 보안 연결을 보여 주면 기록하십시오. 보여 주지 않으면 터널이 검증되었다고 암시하는 대신 보고서에 그렇게 적으십시오.

시뮬레이터 버전, 선택한 장비, 학습 목표를 토폴로지 파일과 함께 보관하십시오. 그 기록이 있어야 다른 사람이 연습을 재현하고 어떤 부분이 모델링되었는지 이해할 수 있습니다.

프로덕션 구성에는 자체적인 플랫폼 증거가 필요합니다. 초록색 시뮬레이션 패킷은 교육 결과이며, 배포할 하드웨어에 대한 호환성 선언이 아닙니다.