기존 GCE VPN 게이트웨이에서 IP 전달 사용 설정

이 VM은 IP 전달을 켜지 않고 만들어졌고 이미 VPN 소프트웨어를 실행하고 있습니다. 그래서 플래그를 켠 템플릿으로 다시 만들고 싶어지지만, 그 재생성은 필요하지 않습니다. Compute Engine은 canIpForward를 업데이트 가능한 속성으로 제공하며, 문서화된 업데이트 경로는 재시작 대신 refresh로 이를 적용합니다. 플래그가 실제로 제어하는 범위는 좁습니다. 플래그가 없으면 플랫폼은 인스턴스에 도착했지만 인스턴스 자체의 주소로 향하지 않은 패킷을 버립니다. 다른 머신의 트래픽을 전달하는 게이트웨이는 바로 그 일을 하므로 플래그가 켜져 있어야 합니다. 그 이후의 모든 것은 게스트 구성과 라우팅이며, 플래그는 여기에 관여하지 않습니다.

플래그가 허용하는 것과 허용하지 않는 것

전달이 비활성화되면 플랫폼은 인스턴스를 끝점으로 취급합니다. 목적지가 인스턴스 자체의 주소인 패킷은 전달되고, 인스턴스가 다른 쪽을 대신해 넘겨야 하는 패킷은 전달되지 않습니다.

전달이 활성화되면 인스턴스는 VPC 경로의 다음 홉 역할을 할 수 있으며, 이것이 VPN 어플라이언스에 필요한 역할입니다. 플래그는 방화벽, 게스트 라우팅, 터널 구성 또는 반환 경로에 대해 아무것도 말하지 않으며, 고장 난 게이트웨이의 true 값은 여전히 고장 난 게이트웨이입니다.

현재 속성 읽기

무엇이든 바꾸기 전에 대상 인스턴스, 프로젝트, 영역에 대해 읽기 전용 describe를 사용해 설정을 확인합니다.

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

false 값은 이 VM이 다음 홉이어야 할 때만 중요합니다. 그렇다면 경로의 나머지 부분은 여전히 별도로 확인해야 합니다. 이 속성은 더 긴 체인에서 한 줄에 불과하기 때문입니다.

기존 인스턴스 업데이트

Google의 인스턴스 속성 업데이트 절차는 현재 리소스를 내보내고, 속성을 수정하고, 결과를 제출합니다. 이는 생성 시점의 --can-ip-forward 플래그와는 다른 워크플로이며, 실행 중인 VM에서 작동하는 방식은 이쪽입니다.

먼저 정의를 로컬 파일로 내보내고, 비교를 위해 변경하지 않은 사본을 보관합니다.

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

그 내보낸 파일에서 속성만 설정하고 다른 것은 바꾸지 않습니다.

canIpForward: true

리소스 전체를 지문까지 포함해 유지합니다. 파일을 한 줄짜리 YAML 문서로 바꾸거나, 머신 유형, 디스크, 인터페이스에 대한 무관한 편집을 같은 제출에 묶으면 속성 변경이 장애로 이어집니다.

실제 변경이 허용되기 전에 업데이트 메커니즘에 파일을 검증하고 무엇이 필요한지 보고하도록 요청합니다.

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

이 검증 실행은 전달을 활성화하지 않습니다. 유효하지 않은 속성과 필요하다고 알려진 작업에 대한 응답을 읽습니다. 이 고립된 변경에서 문서화된 작업은 REFRESH입니다. 결과가 재시작을 요구하면 파일에 변경하려던 속성보다 많은 내용이 들어 있으므로, 재시작을 승인하는 대신 파일을 점검합니다.

검토한 파일을 refresh 제한과 함께 적용합니다.

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

작업이 완료되었는지 확인하고 describe 명령을 다시 실행합니다. 지문이 더 이상 일치하지 않으면 편집하는 동안 다른 사람이 인스턴스를 변경한 것이므로, 오래된 파일을 밀어붙이는 대신 새 사본을 내보내 변경을 다시 검토합니다.

게스트는 여전히 패킷을 라우팅해야 합니다

클라우드 권한이 어플라이언스를 라우터로 만들지는 않습니다. VPC 경로가 대상 접두사에 대해 이 VM을 다음 홉으로 선택하는지, 그리고 게스트가 자체 전달 정책을 켠 상태에서 터널과 올바른 인터페이스 사이를 라우팅하는지 확인합니다.

방화벽 정책은 외부 리스너뿐 아니라 내부 흐름도 허용해야 합니다. VPN 포트만 여는 것은 암호화된 전송을 설명할 뿐 그 안의 애플리케이션 교환에 대해서는 아무것도 말하지 않습니다.

마지막으로 목적지에는 클라이언트 풀로 돌아가는 경로가 필요하거나, 설계가 소스를 의도적으로 변환해야 합니다. 목적지가 변환된 트래픽을 본다면 변환된 소스를 확인하고, 설계가 풀을 유지한다면 반환 경로와 접근 규칙에서 그 풀을 확인합니다. 어떤 설계를 원할지 정하기 전에 NAT를 추가하면 빠진 경로가 가려지고 목적지가 보는 정책이 바뀝니다.

Linux 게이트웨이에서 커널 전달은 게스트 구성의 일부입니다. pfSense 어플라이언스에는 자체적인 동등 기능이 있으며, Linux sysctl 명령을 그 안에 복사하는 것은 대응 단계가 아닙니다.

접근이 필요한 클라이언트에서 검증

게이트웨이 자체가 아니라 VPN 클라이언트에서 하나의 대상 서비스로 테스트합니다. 게이트웨이에서 시작한 연결은 다른 소스를 사용하며 방금 활성화한 전달 규칙을 전혀 거치지 않습니다.

어플라이언스를 관리하는 모든 곳에 이 속성을 기록합니다. 수동으로 수정한 VM은 다음 교체 때 원래 설정이 조용히 되살아날 때까지 동작하며, 그 실패는 VPN 소프트웨어의 회귀처럼 보일 것입니다.

작업 순서는 속성을 읽고, 내보내 한 줄을 편집하고, NO_EFFECT로 검증하고, REFRESH로 적용하고, 게스트가 전달하는지 확인한 다음, 클라이언트에서 테스트하는 것입니다.