OpenVPN 클라이언트를 Cloudflare로 라우팅할까? 먼저 역할을 확인하세요
기기 클라이언트는 라우터가 아닙니다. Cloudflare 역할이 다른 호스트의 패킷을 전달하는지 확인한 다음, 서버 자체의 터널은 예전 경로에 그대로 두세요.
작동하는 OpenVPN 서버와 Cloudflare의 기기 소프트웨어도 실행하는 호스트가 있고, 다음의 명백한 단계는 클라이언트 트래픽을 그쪽으로 보내는 것처럼 보입니다. 한 머신에서 작동하는 두 연결이 합쳐져 트랜짓 게이트웨이가 되지는 않습니다. 빠진 것은 다른 사람에게 속한 패킷을 전달하도록 문서화된 역할과, 그 패킷이 도착할 때 분류하는 정책입니다.
어떤 규칙보다 먼저 네 가지 질문이 있습니다: 어떤 트래픽이 들어오는가, 다음에 어디로 가는가, 응답은 어떻게 돌아오는 길을 찾는가, 그리고 두 번째 경로가 실패할 때 설계는 무엇을 하는가. 처음 두 가지는 역량에 관한 질문입니다.
한 호스트의 두 서비스는 트랜짓 경로가 아닙니다
기기 클라이언트는 자신이 실행되는 머신에서 발생하는 트래픽을 처리하도록 만들어졌습니다. 이름 확인 또는 선택된 애플리케이션 트래픽을 가로채 자신의 터널로 보내며, 그 정책은 해당 기기의 사용자와 해당 기기의 프로세스를 위해 작성되어 있습니다. OpenVPN 클라이언트에서 전달된 패킷은 로컬 출력이 아니므로 같은 규칙이 그것을 분류하지 않습니다. 이는 더 넓은 규칙으로 덮을 수 있는 설정 세부 사항이 아니라, 소프트웨어가 그 패킷을 아예 보는지를 결정합니다.
그래서 설계 질문은 역량 질문입니다. 설치된 제품에 다른 네트워크를 위한 트래픽을 전달하는 문서화된 역할이 있거나, 트랜짓 기능이 완전히 다른 곳에 속해 있습니다.
Cloudflare의 어떤 역할이 전달할 수 있는가
Cloudflare의 기기 클라이언트는 범위가 다른 모드를 제공합니다: 이름 확인만, 기기에서 오는 트래픽, 때로는 둘 다입니다. 그 어느 모드도 다른 터널을 통해 도착하는 사설 범위에 대해 호스트를 라우터로 만들지 않습니다. 전용 라우팅 역할은 자체 커넥터, 등록, 네트워크 모델을 가진 별도 제품입니다.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
그 주위로 경로를 설계하기 전에 설치된 역할을 확인하세요. 커넥터가 어떤 인터페이스를 만드는지, 특정 프리픽스나 기본 경로를 알리는지, 로컬 정책이 로컬 패킷뿐 아니라 전달된 패킷에도 적용되는지 읽으세요. 로컬 트래픽만 처리된다면, 번역 규칙이 어떻게 작성되든 OpenVPN 서버는 트랜짓 지점이 될 수 없습니다.
여기서 공인 출구 요구 사항도 정확히 진술해야 합니다. 전달된 클라이언트 트래픽을 위해 Cloudflare가 제공하는 출구는 특정 사용 사례이며, 실제로 가진 서비스에 비추어 확인해야 합니다.
바깥 터널을 새 경로와 독립적으로 유지하세요
새 인터페이스로 기본 경로를 추가하는 순간, 서버 자체의 아웃바운드 트래픽이 그것을 두고 경쟁하기 시작하며, 여기에는 OpenVPN 클라이언트에 대한 응답과 머신으로의 SSH 세션도 포함됩니다. 흔한 증상은 연결되었다가 죽는 터널, 또는 변경이 성공한 것처럼 보이는 동안 밖으로 잠기는 관리자입니다. 엔드포인트에 대해 ip route get을 변경 전과 후로 비교하고, 정책 라우팅이나 호스트 경로를 사용해 서버 자체의 전송을 원래 있던 곳에 유지하세요. 그 비교는 머신 자체에서 실행하세요, 서버가 자기 경로에 대해 가지는 시각이 중요한 것입니다.
서버의 공인 주소에 대한 예외만으로는 충분하지 않습니다, 각 원격 관리자의 반환 경로는 다른 흐름이기 때문입니다. 그 흐름 중 어느 것이 변경을 견뎌야 하는지 결정하고, 첫 번째가 나머지를 덮는다고 가정하는 대신 각각을 검증하세요.
전달과 번역을 하나의 흐름으로 제한하세요
수신된 패킷은 로컬 출력 경로가 아니라 전달 경로를 따르므로, 중요한 규칙은 forward 훅에 있습니다. 다음 인터페이스에 번역이 필요하면 출발지를 클라이언트 풀로, 목적지를 허용된 것으로, 출구를 그 단일 인터페이스로 제한하세요. 인터페이스에만 묶인 masquerade 규칙은 스스로 어떤 경로도 선택하지 않으며 다른 어떤 필터도 넘어 전달을 허용하지 않습니다.
실패 시 닫히는 동작을 미리 결정하고, 그다음 시험하세요. 다음 경로를 멈추고 클라이언트가 조용히 일반 업링크로 되돌아가는 대신 의도한 출구를 잃는지 확인하세요, 트래픽이 잘못된 문으로 나갈 때까지 아무도 알아차리지 못하는 결과가 바로 그것입니다. 이름 확인과 IPv6에 대해서도 검사를 반복하세요, v4 전용 규칙 집합은 v6 경로를 열어 둡니다.
정한 네 가지 답과 각각을 입증하는 관찰을 적어 두세요. 설명할 수 있는 트랜짓 경로는 다음 사고 검토에서 변호할 수 있는 경로입니다.