하나의 AWS Client VPN 세션 뒤에 있는 LAN: 무엇이 전달되는가

노트북이 AWS Client VPN 엔드포인트에 연결되고 프라이빗 서브넷에 도달하며 모든 것이 정상으로 보입니다. 같은 LAN의 데스크톱은 아무것도 도달하지 못합니다. Linux 호스트에도 브리지 인터페이스가 있고 두 머신이 같은 케이블에 있는데도 그렇습니다. 터널에는 잘못 설정된 것이 없습니다. 빠진 조각은 라우팅이고 브리지는 잘못된 단서입니다.

Client VPN 세션을 LAN으로 확장하는 것은 게이트웨이 역할입니다. 관리형 서비스 안으로 늘어난 Ethernet 세그먼트가 아닙니다.

호스트는 되고 LAN은 안 된다

Linux 머신의 터널 인터페이스에는 Client VPN 클라이언트 CIDR 안의 주소가 있고, 엔드포인트는 VPC 범위에 대한 경로를 밀어 넣었습니다. 그 머신에서 만든 요청은 로컬에서 생성된 트래픽입니다. 경로를 선택하고 터널을 통해 나가 응답을 받습니다. 그 경로는 전달 코드, LAN 인터페이스, 트랜짓을 관장하는 어떤 방화벽 규칙도 건드리지 않습니다.

다른 LAN 장치에서 오는 트래픽은 다른 흐름입니다. LAN 인터페이스로 도착하고, 터널을 가리키는 경로가 필요하고, 전달이 켜져 있어야 하고, 그것을 허용하는 방화벽이 필요하고, 응답이 같은 호스트를 통해 돌아와야 합니다. 네 가지 조건인데, 동작하는 노트북 테스트는 그중 어느 것도 증명하지 않습니다. 데스크톱에서는 장애가 이상해 보입니다. 터널은 올라가 있고 자격 증명은 유효한데 목적지가 그냥 응답하지 않습니다. 결함은 게이트웨이의 전달 경로에 국한되며 서비스에는 없습니다.

모든 클라이언트가 게이트웨이가 될 수는 없다

AWS는 자사의 Client VPN 데스크톱 앱이 IP 전달을 지원하지 않으며 다른 클라이언트는 지원할 수 있다고 밝힙니다. 이 제약은 명령을 한 줄 입력하기 전에 아키텍처를 결정합니다. 사용할 수 있는 클라이언트가 공식 데스크톱 앱뿐이라면, LAN을 위해 전달하는 Linux 게이트웨이는 완성할 수 있는 구성이 아니며, 아무리 masquerading을 해도 바뀌지 않습니다.

대체 클라이언트는 엔드포인트의 인증 방식과 적용하려는 정책에도 맞아야 합니다. 인증서 기반, 디렉터리 기반, SAML 기반 엔드포인트는 같은 클라이언트 구성을 받아들이지 않으며, 인증은 하지만 밀어 넣은 경로를 무시하는 서드파티 클라이언트는 개선이 아닙니다.

클라이언트 선택을 설계 검토의 일부로 다루십시오. LAN 전달 패턴이 애초에 가능한지, 그리고 게이트웨이 뒤의 각 장치에 대해 엔드포인트가 어떤 ID를 보는지를 결정합니다. 클라이언트와 시험한 엔드포인트 구성을 기록하십시오. 반년 뒤의 클라이언트 교체는 설계가 전제한 능력을 조용히 없앨 수 있습니다.

LAN을 터널로 보내고 변환한다

지원되는 클라이언트가 있으면 나머지는 평범한 게이트웨이 작업입니다. LAN 장치에는 VPC 범위에 대해 Linux 호스트를 가리키는 경로가 필요하고, 호스트에는 전달이 켜져 있어야 합니다. VPC가 트래픽을 임의의 LAN 주소가 아니라 연결된 클라이언트로 보게 하려면 나갈 때 출발지를 변환합니다.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

규칙은 위와 같이 터널 인터페이스와 VPC 범위로 한정하고, 호스트가 전달하는 모든 것을 masquerade하지 마십시오. 좁은 규칙이 따지기 쉽고, 원래 출발지 주소를 유지해야 했던 트래픽을 조용히 바꾸지도 않습니다.

가능하면 LAN 경로가 자동으로 도착하게 하십시오. DHCP 옵션, 라우터 알림, 또는 LAN을 관리하는 무언가가 밀어 넣는 정적 경로입니다. 시험 머신 한 대에만 존재하는 경로는 다른 누군가가 시도하는 순간 설계를 깨진 것처럼 보이게 합니다.

응답에도 경로가 필요하다

요청이 VPC에 도달하면 응답은 같은 변환 상태를 거쳐 돌아와 게이트웨이에서 LAN 경로를 찾아야 합니다. 이 부분은 masquerade 규칙이 있을 때 보통 동작합니다. 매핑이 그것을 수행한 호스트에 살기 때문입니다. VPC 쪽에 응답을 다른 곳으로 보내는 경로가 있으면 깨집니다. 그래서 클라이언트 CIDR 경로와 엔드포인트의 서브넷 연결이 모두 중요합니다.

ping만 보지 말고 카운터를 보십시오. 패킷이 하나도 없는 masquerade 규칙은 요청이 터널 인터페이스에 도달하지 않았다는 뜻이며, 이는 LAN 경로나 클라이언트 자체의 라우팅 테이블을 가리킵니다. 패킷은 있지만 응답이 없는 규칙은 VPC 쪽, 권한 부여 규칙, 또는 변환된 출발지를 받아들이지 않는 보안 그룹을 가리킵니다. 무엇이든 바꾸기 전에 양방향을 읽으십시오. 한쪽에서만 늘어나는 수는 느린 경로가 아니라 일방통행 경로입니다.

엔드포인트가 관리형 서비스임을 기억하십시오. 편집할 서버 구성 파일도, 추가할 client-config 지시문도 없으므로 사용자 지정 클라이언트 서브넷 경로가 있는 자체 관리 OpenVPN 서버용으로 작성된 지침은 그대로 옮겨지지 않습니다. AWS에서는 서브넷 연결, 권한 부여 규칙, VPC 라우팅 테이블이 지렛대입니다.

공유 ID는 정책이 답해야 하는 부분이다

게이트웨이 뒤의 모든 장치는 게이트웨이의 VPN 세션을 사용합니다. 엔드포인트의 권한 부여 규칙은 사용자나 그룹에 접근을 허용하며, 서비스 관점에서 그 세션에는 정확히 한 명의 사용자가 있습니다. 로컬 전달은 그 ID를 장치별 인증으로 늘리지 않으며, 장치 상태 검사를 구석의 프린터까지 확장하지도 않습니다.

그것이 받아들여질 수도 있고, 설계가 거부되는 이유가 될 수도 있습니다. VPC 리소스가 누가 호출하는지에 대해 무엇을 전제하는지에 달려 있습니다. 권한 부여 모델에 맞는 공유 ID는 괜찮습니다. 인증된 단일 세션을 조용히 LAN 전체 접근으로 바꾸는 것은 기록되기를 기다리는 발견입니다.

요구가 정말로 사이트 전체를 VPC에 연결하는 것이라면, 원격 접속 클라이언트를 확장하기 전에 지원되는 사이트 간 설계와 비교하십시오. 의미가 다르고, VPC가 LAN으로 연결을 시작해야 할 때 NAT된 클라이언트 세션은 사이트 링크의 빈약한 대체물입니다.

클라이언트, 경로, 변환, ID 이야기를 이 순서로 결정하십시오. 각각이 다음을 제약하며, 이 순서가 호스트는 되고 LAN은 안 되는 이유를 설명합니다.