VPN 서버와 클라이언트를 겸하는 pfSense: 두 갈래 길, 하나의 라우터

한 장비가 동시에 두 방향을 바라볼 수 있습니다: 이동 중인 사용자는 안쪽으로 접속하고, 같은 상자는 선택한 트래픽이 다른 네트워크로 나가도록 바깥의 출구 제공자에게 접속합니다. 두 서비스를 켜는 데는 몇 분이 걸리지만, 두 번째 역할이 첫 번째가 의존하는 라우팅 테이블을 다시 쓰기 때문에 함께 살게 하려면 설계가 필요합니다. 이 구성이 되는지를 세 조건이 결정합니다: 인바운드 서비스가 자기 반환 경로를 지키는지, 아웃바운드 터널이 여전히 상대에 닿는지, 전달하려던 트래픽이 출구로 선택되는지입니다. 하나만 틀려도 둘 다 연결됨을 보고하면서 그 사이로 유용한 것이 지나지 않는 터널 두 개가 됩니다. 아래 점검은 장애가 보통 나타나는 순서대로 각 조건을 확인합니다.

설정을 건드리기 전에 두 역할의 이름을 붙이세요

각 인스턴스마다 원격 상대, 인증 자료, 배포하는 주소 풀, 그 뒤의 네트워크라는 네 가지 사실을 적습니다. 두 인스턴스는 장비 위에서 별개의 객체이며 노트에서도 분리되어야 합니다. 나중에 생기는 혼란스러운 증상의 거의 전부가 두 값이 섞이는 데서 오고, 두 인스턴스가 노트 한 벌을 공유하는 것이 잘못된 풀이 잘못된 칸에 들어가는 길입니다.

인바운드 서비스에는 아웃바운드 터널의 주소와도, 장비가 라우팅하는 어떤 사설 네트워크와도 겹치지 않는 터널 네트워크가 필요합니다. 겹침은 두 역할에서 동시에 증상을 만드는 유일한 실수이며, 종이 위에서 잡는 편이 훨씬 쌉니다. 어느 한 서비스를 구성하기 전에 두 풀과 라우팅되는 모든 사설 네트워크를 한곳에서 비교하세요.

하드웨어를 공유한다고 자격 증명을 공유하는 것은 아니며, 원격 접속 풀의 클라이언트 인증서가 출구 제공자에 대해 쓸 수 있어서는 안 됩니다. 자료를 분리하면 폐기도 전체 플릿의 사건이 아니라 로컬 결정이 됩니다.

서버의 응답을 WAN 경로에 두세요

장비가 스스로 만드는 응답은 부주의한 기본 경로의 첫 희생물입니다. 이동 중인 사용자의 캡슐화된 패킷이 도착하면 응답은 로컬에서 생긴 트래픽이고, 그 사용자가 들어온 인터페이스로 나가야 합니다. 아웃바운드 클라이언트가 그것을 붙잡는 기본 경로를 넣어 두면 응답은 잘못된 터널로 들어가고, 서비스는 여전히 건강해 보이는 동안 세션이 멈춥니다.

결정은 아웃바운드 클라이언트가 어느 트래픽을 붙잡을 수 있는지에 관한 것이므로, 이것을 정하는 단일 체크박스는 없습니다. 경로를 전혀 당기지 않고 고른 것만 보내거나, 경로를 당기고 장비 자체 서비스를 계속 돌리는 예외를 더합니다. 선택을 인스턴스 옆에 적으세요, 그러지 않으면 다음 사람이 다른 쪽을 전제합니다.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

라우팅 테이블은 무엇을 구성한 순서가 아니라 가장 긴 일치로 읽으세요. 질문은 출구 상대의 주소에 어느 항목이 이기는지, 인바운드 서비스의 응답에 어느 항목이 이기는지이며, 두 답은 다를 수 있습니다.

아웃바운드 터널이 자기 끝점을 먹게 두지 마세요

아웃바운드 클라이언트는 터널을 세우려면 상대의 공인 주소에 닿아야 합니다. 그 주소 자체가 터널로 라우팅되면 클라이언트는 자기 꼬리를 쫓습니다: 전송이 아예 올라오지 않거나, 올라왔다가 경로가 설치되는 순간 떨어집니다. 로그는 라우팅 결함이 아니라 인증 시간 초과처럼 보이므로 경로를 먼저 확인할 가치가 있습니다.

항목이 부팅 때는 맞고 잠시 뒤에는 틀릴 수 있으므로, 자격 증명 전에 경로를 확인하고 터널이 올라온 뒤에 다시 확인하세요. 상대의 주소는 일반 WAN 경로를 가리켜야 하고, 터널 장치를 가리켜서는 안 됩니다. 전송이 안정되면 관심은 전달 트래픽으로 옮겨가고, 그것이 다음 결정입니다.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

어느 사용자에게 출구를 줄지 고르세요

소스 정책은 트래픽이 장비로 들어오는 입구에 속하므로 원격 접속 풀, 또는 그 안의 더 좁은 신원을 고릅니다. 출구로 절대 보내면 안 되는 사설 목적지와 관리 예외를 보존하고, 그 규칙을 넓은 규칙 앞에 둡니다. 그러면 출구 경로에는 자체 변환이나 라우팅된 반환 구성이 필요하고, 대부분의 설계에서는 풀을 덮는 출구 인터페이스의 아웃바운드 NAT를 뜻합니다. 변환은 출구를 고르지 않고 이미 나간 것을 다시 쓸 뿐이므로, 무관한 WAN의 NAT 규칙은 선택에 아무것도 바꾸지 않습니다.

허용하는 제공자도 있고 아닌 곳도 있으므로, 원격 측이 이 설계에서 전달되는 트래픽을 허용하는지 확인하세요. 차이는 연결되지만 아무것도 나르지 않는 터널로 나타나며, 로컬 결함으로 잘못 읽기 쉽습니다. 세 흐름을 따로 시험하세요, 서로 독립적으로 실패하고, 셋 중 둘이면 절반만 지은 설계입니다.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

첫 명령은 이동 중인 사용자의 바깥 연결이고, 클라이언트가 초기화 순서가 끝났다고 보고하면 동작합니다. 둘째는 그 연결된 노트북에서 실행하며, 당신의 WAN 주소가 아니라 출구 제공자의 주소를 보고해야 합니다. 셋째는 장비에서 풀 주소에 묶여 실행되고, 원격 사용자를 전혀 끌어들이지 않고 전달 트래픽의 소스 정책을 시험합니다. 대신 WAN에서 응답한다면 정책이 맞지 않은 것이고, NAT 편집으로는 선택 문제가 고쳐지지 않습니다.

출구가 실패할 때 무슨 일이 일어날지 정하세요

실패 동작을 일어나기 전에 적습니다: 아웃바운드 터널이 떨어지면 사용자가 일반 WAN으로 돌아가는지, 아니면 출구가 돌아올 때까지 차단되는지입니다. 둘 다 변호할 수 있고, 장비가 대신 골라 주지 않습니다. 지운 경로나 죽은 게이트웨이를 가리키는 정책이 자동으로 완전 차단 결과를 만들지는 않습니다. 차단을 원하면 정책이 그것을 분명히 말해야 하고, 출구를 빼서 시험해야 하며 머릿속으로 따져서는 안 됩니다. 되돌림을 원하면 사용자에게 알리세요, 조용히 일반 경로를 택하는 트래픽이야말로 누군가 덮였다고 믿은 트래픽입니다.

클라이언트 인스턴스를 끄고, 연결된 사용자가 여전히 무엇에 닿는지 보고, 다시 시작하세요. 시간이 다 되는 요청이 당신이 요청한 완전 차단 결과이고, WAN 주소로 응답하는 요청이 문서화하지 않은 되돌림입니다. IPv4용으로 쓴 정책은 AAAA 트래픽에 대해 아무 말도 하지 않고 어느 터널이 밀어 넣은 리졸버든 질의가 실제로 나가는 곳에서 응답하므로, IPv6와 DNS에 대해서도 점검을 반복하세요.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgate의 라우팅된 OpenVPN 방식 은 소스 정책, 인터페이스 배정, 아웃바운드 변환이 어떻게 맞물리는지 보여 주며, 사이트 간 범위가 그대로 베끼지 말아야 할 부분입니다. 그것이 말해 주지 않는 것은 위의 세 조건 중 무엇을 당신의 설계가 이미 깨뜨렸는지입니다.