NIC가 여러 개인 GCP VM: 응답이 잘못된 인터페이스로 나가는 이유

Compute Engine VM에 두 번째 인터페이스를 연결하면 네트워크 연결이 하나 더 생길 뿐, 대칭적인 반환 경로가 생기는 것은 아닙니다. 게스트는 여전히 자신의 경로와 규칙에서 인터페이스와 원본 주소를 고릅니다. 그다음 Google Cloud는 패킷이 나간 인터페이스를 기준으로 VPC 라우팅과 방화벽 정책을 적용합니다. 이 두 결정이 어긋나면 요청은 한 NIC로 도착하고 응답은 다른 NIC로 나가며, 지사는 반쯤 열린 대화를 보게 됩니다.

다섯 단계로 경로를 따라가면 정책 규칙을 쓰기 전에 불일치가 드러납니다.

1단계: 클라우드 NIC를 게스트 장치에 매핑하기

클라우드는 인터페이스에 nic0, nic1 같은 이름을 붙이고, 게스트는 반드시 일치하지는 않는 장치 이름을 봅니다. 무엇보다 먼저 인스턴스 메타데이터나 인터페이스 자체의 주소에서 매핑을 풀어야 합니다. DHCP가 제공하는 일반 기본 경로는 nic0에 연결되어 있어 인터넷 쪽 경로가 우연히 이기는 경우가 많습니다. 추측한 장치 이름으로 정책을 쓰는 것이 올바른 규칙을 잘못된 인터페이스에 놓는 방식입니다.

주소, 장치 이름, 각각이 속한 VPC를 기록하세요. 그 세 열 지도가 이후 모든 단계의 입력입니다.

2단계: 두 가지 라우팅 결정에 이름 붙이기

첫 번째 결정은 게스트의 몫으로, 이 패킷에 어떤 인터페이스와 어떤 원본 주소를 쓸지 정합니다. 두 번째는 클라우드의 몫으로, VPC 경로와 방화벽 정책이 그 인터페이스 주변에서 무엇을 허용하는지 정합니다.

VPN 쪽 VPC에서 보이는 경로가 그 NIC를 선택하는 게스트 경로가 되지는 않습니다. 클라우드 경로는 네트워크가 전달할 수 있는 것을 설명하고, 게스트 경로는 패킷이 하는 일을 정합니다.

3단계: 반환 경로 정책 고르기

지사 프리픽스의 작고 안정적인 집합에는 게스트의 명시적 목적지 경로가 가장 단순한 표현이며, 그 프리픽스로 가는 응답은 VPN 쪽 인터페이스로 나갑니다. 여러 서비스가 의도적으로 서로 다른 로컬 원본 주소를 쓸 때, 인터페이스마다 테이블을 고르는 원본 기반 규칙이 각 응답을 올바른 맥락에 둡니다. 여러 인터페이스 문서는 이 설계가 의존하는 NIC 이름 규칙과 기본 경로 동작을 설명합니다.

각 테이블에는 유효한 연결 경로와 다음 홉, 그리고 그 테이블에 물어볼 목적지가 필요합니다. 불완전한 테이블을 가리키는 규칙은 반환 경로 설계가 아닙니다. 서브넷의 겉모습에서 Ethernet 게이트웨이를 지어내지 말고 그 NIC에 문서화된 게이트웨이를 사용하세요.

4단계: 게스트 자체 필터 확인하기

서버가 어디에서 수신하는지, 응답이 어떤 로컬 원본을 담는지 확인하세요. 모든 주소에서 수신하는 리스너는 라우팅 정책을 덮어쓰지 않으므로, 모든 주소에 바인딩해도 응답이 나가는 인터페이스는 달라지지 않습니다.

Linux에서는 의도한 설계에 비추어 역경로 검증을 검토하세요. 첫 조치로 이를 전역에서 끄면 라우팅 버그를 스푸핑 노출과 맞바꾸고, 찾으려던 비대칭을 숨기게 됩니다.

5단계: 경로마다 흐름 하나씩 시험하기

허용된 지사 요청과 무관한 인터넷 요청을 각각 실제 원본과 목적지를 사용해 따로 검증하세요. 가능하면 두 인터페이스 모두에서 캡처하세요, 유용한 증거는 어느 인터페이스가 응답을 실었는지이기 때문입니다. 그다음 클라우드 쪽 정책이 설계한 경로를 존중했는지 확인하세요. 성공한 요청 하나는 흐름 하나를 증명할 뿐, 대칭 설계를 증명하지 않습니다.

두 시험은 서로 다른 경로와 서로 다른 방화벽 규칙을 사용하므로 메모에서 분리해 두세요.

두 번째 NIC가 주지 않는 것

두 번째 인터페이스는 네트워크 연결과 주소 하나를 더합니다. 자동 대칭 라우팅을 더하지도 않고 방화벽 정책을 우회하지도 않습니다. 이를 라우팅 수정으로 보는 것이 다중 NIC 설계에 나중에 아무도 설명할 수 없는 규칙이 쌓이는 이유입니다.

VM이 다른 머신의 트래픽을 전달해야 한다면 전달을 허용하는 클라우드 설정과 그에 따르는 게스트 필터도 포함해 그 라우터 역할을 명시적으로 계획하세요.