사이트 간 VPN을 통한 ASA DHCP 릴레이: 단계별 안내

릴레이는 세 단계로 동작하며 VPN을 건너는 것은 가운데 단계뿐입니다. 클라이언트가 지사 세그먼트에서 브로드캐스트를 보내면 ASA가 이를 DHCP 서버로 가는 유니캐스트 요청으로 바꾸고, 서버는 클라이언트가 아니라 릴레이 주소로 응답합니다. 이 순서대로 단계를 짚어 보면 «릴레이가 고장 났다»는 대부분의 사례가 빠진 정책이나 잘못 읽은 setroute 줄로 귀결됩니다.

첫 번째 단계: 클라이언트 쪽 인터페이스에서 릴레이 활성화

지사의 ASA에서 릴레이는 클라이언트를 향한 인터페이스의 속성입니다. 서버는 도달 가능한 인터페이스와 함께 전역으로 선언하거나, 라우팅 테이블이 출구를 고르도록 그 클라이언트 쪽 인터페이스 아래에 선언할 수 있습니다. 이 두 형태는 서로 바꿔 쓸 수 없으며, 잘못된 쪽을 복사하는 것이 안내가 처음 어긋나는 지점입니다.

무엇이든 바꾸기 전에 실행 중인 구성을 확인하십시오. 어느 인터페이스에서 릴레이가 켜져 있는지, 어떤 서버 형태가 있는지, setroute이 클라이언트 인터페이스에 붙어 있는지입니다. ASA가 다른 세그먼트용 DHCP 서버도 함께 운영한다면 멈추고 제한 목록을 읽으십시오. 서버와 릴레이는 같은 장비에서 동시에 활성화할 수 없습니다.

릴레이는 자신의 클라이언트 쪽 주소를 게이트웨이 주소 필드에 넣습니다. 서버가 응답하는 대상이 바로 이 주소이므로, 로컬뿐 아니라 터널을 통해 원격 사이트에서도 도달할 수 있어야 합니다.

두 번째 단계: ASA가 만드는 트래픽을 터널로 실어 보내기

사람들이 건너뛰는 단계입니다. 정책 기반 사이트 간 VPN은 보통 서브넷 사이의 트래픽을 위해 구축되고, 릴레이 요청은 ASA 자신이 만듭니다. 터널의 액세스 목록과 크립토 맵이 지사 호스트에서 서버 서브넷으로 가는 흐름에만 일치하면 릴레이 패킷은 터널에 아예 들어가지 못할 수 있습니다. 액세스 목록은 양방향으로 확인하십시오. 지사에서 서버로 가는 줄만 봐서는 부족합니다.

관심 트래픽이 ASA의 릴레이 출발지와 서버 주소를 포함하는지, 되돌아오는 방향도 허용되는지 확인하십시오. VTI 기반 설계에서는 라우팅 결정이 더 단순하지만, VTI를 통한 릴레이 지원은 특정 릴리스에서 들어왔습니다.ASA DHCP 안내서 는 9.14(1)을 명시하므로, 구형 장비에 VTI 예제를 복사하기 전에 이미지를 확인하십시오.

ASA에서 서버로 보내는 ping만으로는 증명되는 것이 거의 없습니다. 다른 경로로, 다른 출발지 주소로, 또는 릴레이 패킷이 맞지 않는 정책 아래에서도 성공할 수 있습니다.

세 번째 단계: 응답과 setroute 옵션 읽기

RFC 2131은 그 필드가 영이 아닐 때 서버가 응답을 giaddr의 주소로 보낸다고 말합니다. 따라서 돌아오는 경로는 릴레이 주소로 라우팅되어야 하며, 터널 정책은 서버에서 릴레이 방향을 허용해야 합니다. 요청은 지나갔는데 제안이 끝내 도착하지 않는다면 여기를 봐야 합니다.

다음으로 비슷하게 들리는 두 가지를 구분하십시오. setroute 키워드는 ASA가 클라이언트에 주는 기본 라우터 옵션을 바꾸거나 추가합니다. ASA에 경로를 설치하지 않고 VPN 정책을 만들지도 않습니다. 주소는 받았는데 아무것도 도달하지 못하는 클라이언트는 대개 터널 문제가 아니라 setroute나 스코프 문제입니다. 정적 게이트웨이가 없는 클라이언트로 시험하고 제안에 어떤 기본 라우터가 나타나는지 보십시오.

제안을 처음부터 끝까지 읽으십시오. 제안 주소, 마스크, 기본 라우터, DNS, 임대 시간입니다. 그다음 임대가 갱신되게 하십시오. 한 번은 동작하고 갱신에서 실패하는 릴레이는 보통 첫 교환이 가려 버린 스코프, 임대, 반환 경로 문제를 갖고 있습니다.

고쳐졌다고 말하기 전에 확인하는 것

클라이언트에서 시작해 브로드캐스트를 잡고, ASA가 자신의 주소를 giaddr로 사용해 이를 릴레이했는지 확인하십시오. 원격 쪽에서는 서버가 그 요청을 보았고 지사에 맞는 스코프를 골랐는지 확인하십시오. 지사로 돌아와 클라이언트가 제안을 받아들였고 게이트웨이에 도달하는지 확인하십시오.

어느 단계가 조용하다면 릴레이 문장을 더 넣지 말고 해당 정책이나 경로를 확인하십시오. 누군가 에스컬레이션할 즈음 릴레이 구성은 대개 이미 맞습니다. 달라진 것은 터널 정책이나 반환 경로입니다.

세 단계를 변경 기록에 적으십시오. 클라이언트 쪽 인터페이스, 릴레이 트래픽을 포함하는 VPN 정책, 서버에서 giaddr으로 돌아가는 경로입니다. 이 기록이 다음 지사 구축을 디버깅 세션이 아니라 반복 가능한 작업으로 만듭니다. 다음 엔지니어가 어떤 명령 출력을 먼저 모아야 하는지도 이 기록이 알려 줍니다.