L2TP, GRE, IPsec: 세션을 어느 계층이 실어야 할까?

L2TP, GRE, IPsec이 같은 설계 메모에 등장하면 두 질문이 얽힙니다—나는 어떤 세션을 싣고 있고, 어느 계층이 그것을 보호하는가? 첫 질문을 틀리면 하위의 모든 것이 내부적으로 일관된 채 잘못된 문제를 풉니다—사용자가 전화 접속해야 할 곳에 라우팅된 오버레이를 짓거나, 사이트 간 게이트웨이 대신 전화 접속 집중 장치를 두는 식입니다. 아래 워크시트는 누군가 장비에 로그인하기 전에 그 구분을 강제합니다. 순서대로 채우면 각 행이 따로 시험할 수 있는 것이 됩니다.

프로토콜 목록이 아니라 세션에서 시작하세요

PPP 세션을 가진 원격 사용자와 두 게이트웨이 사이의 라우팅된 오버레이는 둘 다 결국 IPsec으로 감싸이더라도 서로 다른 네트워크 관계입니다. 전자는 사용자별 링크를 종단하며 주소 할당, 사람 또는 장치 인증, 그 사용자가 도달할 수 있는 내부 네트워크를 지정하는 정책이 필요합니다. 후자는 아무도 전화 접속하지 않는 사이트 사이에서 패킷을 전달합니다.

둘 중 무엇을 짓는지 한 문장으로 쓰고, 그것을 운영할 사람의 입장에서 다시 읽어 보세요. 그 문장에 '그리고'가 필요하면 둘 다 짓는 것이며, 워크시트에는 각각을 반만 섬기는 타협 한 칸이 아니라 두 칸이 필요합니다. 사용자를 언급하면서 주소 풀이 없거나, 접두사를 언급하면서 전달 정책이 없으면 그 문장은 아직 불완전합니다. 표현이 관료적으로 들리지만, 그렇지 않으면 헬프데스크 티켓으로 발견될 설계를 잡는 가장 싼 지점입니다.

각 계층에 정확히 하나의 작업을 주세요

L2TPv2는 두 끝점 사이에서 PPP 세션을 싣습니다. PPP는 링크 협상을, 협상될 때는 사용자 인증을 수행하고, L2TP는 어떤 암호화도 추가하지 않으므로 맨 L2TP 데몬은 IPsec 보안 관계를 전혀 구현하지 않으며 이미 신뢰하는 링크 안쪽에만 속합니다.

GRE는 두 주소 사이의 캡슐화입니다. 논리적 오버레이를 가로질러 네트워크 계층 패킷을 실으며, 그 자체로는 기밀성도 인증된 피어 신원도 제공하지 않습니다. 이는 결함이 아닙니다—헤더는 전달 하드웨어에서 저렴하게 처리되도록 단순하게 설계되었습니다. 그 결과 GRE는 '이 패킷을 두 주소 사이에서 어떻게 옮길까'에만 답하고 그 밖에는 답하지 않고, 바로 물어야 할 질문입니다.

그래서 IPsec이 트래픽을 선택하고, 피어를 인증하며, 보호하라고 지시받은 것을 암호화하는 계층으로 남습니다. 무엇을 보호할지는 구성 결정이며, 끝점이 실제로 생성하는 캡슐화와 일치해야 합니다—GRE 외부 주소용으로 쓴 정책은 내부 접두사용 정책과 다르게 동작하기 때문입니다. GRE 명세는 페이로드, GRE 헤더, 외부 전달 프로토콜을 눈에 띄게 분리하며, 정책에도 같은 분리가 필요합니다.

구성보다 먼저 패킷 경로를 쓰세요

패킷 하나를 골라 추가되는 모든 헤더를 추가 순서대로 나열하고, 그것을 추가하는 장비를 지목하세요. 전화 접속 사용자라면 보통 PPP가 L2TP 안에, 그다음 IPsec 안에 있습니다—사이트 오버레이라면 내부 IP 패킷이 GRE 안에, GRE가 IPsec 안에 있습니다. 두 장비가 같은 헤더를 추가하면 루프나 중복 터널이 있고, 정책을 아무리 고쳐도 고쳐지지 않습니다.

같은 목록이 MTU를 정합니다—쓸 수 있는 내부 크기는 측정한 경로 MTU에서 방금 나열한 헤더를 뺀 것이고 그 밖에는 없습니다. 포럼 게시물에서 숫자를 복사하지 마세요: 외부 IP, UDP, ESP 오버헤드를 더하고, 다음으로 GRE나 L2TP, 해당하면 PPP를 더한 뒤 실제로 측정한 경로 MTU에서 빼십시오. 큰 전송에서만 나타나는 증상이나, 연결된 뒤 첫 큰 응답에서 죽는 세션은 대개 이 덧셈을 어림짐작한 데서 비롯됩니다.

각 계층을 밖에서 안으로 따로 확인하세요

검사를 순서대로 실행하고 처음 실패하는 곳에서 멈추세요. 각 행은 다른 질문에 답하므로, 실패는 터널이 고장 났다고 말하는 대신 워크시트의 어느 칸을 가리킵니다.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco 장비에서는 대응 조치가 역할에 따라 다르고 정확한 구문은 플랫폼과 릴리스에 따라 다릅니다: IPsec 피어에는 show crypto session, GRE 또는 터널 인터페이스에는 인터페이스 카운터, 전화 접속 역할에는 VPDN 또는 PPP 검증을 사용합니다. PPP를 종단하는 명령 집합은 GRE 지원을 전혀 증명하지 못하고, 동작하는 GRE 인터페이스는 PPP 서비스를 전혀 증명하지 못하므로, 다이어그램의 역할이 아니라 실제로 구성한 역할을 검증하세요.

각 출력은 그것이 속한 워크시트 행 옆에 기록하세요. 장애가 살아 있는 동안 적은 메모는 나중에 기억으로 다시 그린 토폴로지보다 값집니다.

해체 순서를 정하고 다시 검증하세요

해체를 역순으로 하는 데는 이유가 있습니다—보호 대상 트래픽을 IPsec 정책에서 먼저 빼고, 그 정책이 전제한 캡슐화를 제거하세요—그렇지 않으면 정책이 더 이상 없는 인터페이스를 가리킨 채 남고 다음 구성 로드가 무관해 보이는 곳에서 실패합니다. Linux에서는 터널 인터페이스보다 먼저 state와 policy 항목을 지우고, 라우터에서는 터널보다 먼저 crypto map 또는 profile 항목을 제거합니다.

재구성 후 네 가지 승인 관찰을 하나씩 반복하세요: 외부 도달성, 확립된 IPsec 연관, 설계에 포함된 경우 확립된 PPP 세션, 그리고 실제 목적지 주소로의 내부 전달입니다. 초록불 하나는 나머지 셋의 증거가 아니며, 그 틈이 운영에서 가장 오래 살아남는 장애입니다—터널은 올라가고 암호화되었지만 내부 경로가 한 번도 추가되지 않아 아무것도 전달하지 않습니다.

채운 워크시트를 장비 구성 옆에 두세요. 채울 수 없는 칸은 작업이 할당되지 않은 계층이고, 작업이 할당되지 않은 계층은 보통 스택에 있어서는 안 되는 계층입니다.