<aside> ☁️

클라우드웨이브 네트워크 1주차 · 4/5 · 약 5분

클라우드웨이브 부트캠프: 네트워크에서 클라우드 네이티브까지

</aside>

넷째 날에는 Site-to-Site VPN과 Remote Access VPN, IPsec, IKE, SA를 배웠다. VPN은 익숙한 단어였지만 설명하려고 하면 “인터넷 통신을 암호화하는 기술” 정도에서 멈췄다.

수업 내용을 다시 연결해 보니 VPN은 암호화 기능 하나가 아니었다. 어떤 트래픽을 터널로 보낼지 정하는 라우팅, 피어를 확인하는 인증, 키 협상, 실제 데이터 보호 규칙이 함께 맞아야 만들어지는 연결이었다.

이 글에서 확인할 것

• 터널링과 IPsec은 어떤 역할로 구분되는가?
• SA가 단방향이라는 사실은 장애 확인에 어떤 의미가 있는가?
• VPN 연결에서 라우팅과 반환 경로를 함께 봐야 하는 이유는 무엇인가?

터널링과 IPsec은 같은 말이 아니다

터널링은 원래 패킷을 다른 패킷 안에 넣어 별도의 논리 경로로 보내는 방식이다. IPsec은 IP 계층에서 패킷의 기밀성, 무결성, 출처 인증 등을 제공하기 위한 보안 아키텍처다.

각 개념의 역할을 나누면 다음과 같다.

• 라우팅은 어떤 목적지 트래픽을 VPN으로 보낼지 정한다.
• IKE는 피어 인증과 키·보안 연결 협상을 담당한다.
• SA는 실제 트래픽에 적용할 보안 처리 조건을 나타낸다.
• IPsec은 합의된 조건에 따라 패킷을 보호한다.

SA가 단방향이라는 점

가장 새로웠던 개념은 Security Association이 단방향 논리 연결이라는 점이었다. 사용자는 하나의 양방향 VPN으로 보지만, 내부에서는 각 방향의 트래픽을 처리할 SA가 구분된다.

flowchart LR
    A["내부 패킷"] --> B["정책·라우팅 판단"]
    B --> C["Outbound SA로 보호"]
    C --> D["IPsec 터널"]
    D --> E["Inbound SA로 검증·복원"]
    E --> F["상대 내부 네트워크"]
    G["IKE<br/>인증·키·SA 협상"] -.-> C
    G -.-> E

따라서 VPN 장애를 볼 때 터널이 보인다는 사실만으로 양방향 통신이 정상이라고 단정할 수 없다. 반대 방향 SA와 반환 경로, 보안 정책도 함께 확인해야 한다.

전송 모드와 터널 모드

전송 모드는 기존 IP 헤더를 유지하면서 상위 계층 데이터 중심으로 보호한다. 터널 모드는 원래 IP 패킷 전체를 내부 패킷으로 넣고 바깥에 새로운 IP 헤더를 붙인다.