OpenVPN을 통한 공인 접두사: 반환 경로 고치기

터널이 올라오고 클라이언트가 반대편에 ping을 보내는 것을 보면, 그다음 VPN 뒤에 있어야 할 공인 주소가 다른 곳에서 응답하거나 아예 응답하지 않습니다. 이 증상은 보통 암호나 인증서와는 아무 관련이 없습니다. 공급자가 라우팅한 접두사는 IP 경로로 전달되며, 이를 OpenVPN 으로 운반한다는 것은 그 경로를 두 계층에서 재현하고 반환 경로에서 소스 주소를 보존한다는 뜻입니다. WAN을 브리지할 필요는 없고, 주소를 인터페이스에 추가한다고 업스트림 경로가 생기지는 않습니다.

접두사가 먼저 여러분에게 라우팅되어야 한다

블록이 어떻게 전달되는지 공급자에게 물어보세요. 서버의 주소로 라우팅된 접두사는 공급자가 WAN 세그먼트에서 직접 도달하기를 기대하는 주소와 다른 것입니다. 여기서 설명하는 설계는 첫 번째 모델에서만 작동합니다.

공급자가 198.51.100.64/28을 진입 서버로 라우팅하면 해당 범위의 패킷은 서버에 도착하고, 여러분이 전달하지 않는 한 거기서 멈춥니다. 공급자가 대신 그 범위를 업링크로 브리지하면 서버가 그에 대해 ARP로 응답해야 하며, 이는 다른 문제입니다.

OpenVPN을 건드리기 전에 전달 모델을 시험하세요: 외부에서 블록의 주소로 ping을 보내고 어느 인터페이스가 받는지 보세요. 아무것도 도착하지 않으면 어떤 터널 구성도 도움이 되지 않습니다. 주소가 WAN에서 직접 응답하면 공급자는 라우팅이 아니라 브리징을 하고 있으며, 아래 설계는 적용되지 않습니다.

두 가지 라우팅 계층: 커널 경로와 iroute

OpenVPN은 접두사를 두 곳에서 필요로 합니다. 커널은 접두사가 터널 장치에 속한다는 것을 알아야 하므로 전달된 패킷이 기본 경로 대신 OpenVPN으로 들어갑니다. OpenVPN은 어떤 인증된 클라이언트가 접두사를 소유하는지도 알아야 하며, 그것이 클라이언트별 디렉터리의 iroute 항목입니다.

서버 측 경로는 다음과 같고, 접두사와 마스크는 할당과 일치해야 합니다:

ip route add 198.51.100.64/28 dev tun0

클라이언트별 구성이 소유권을 지정합니다. 클라이언트 인증서의 일반 이름을 딴 CCD 파일에 넣고, 서버가 실제로 읽는 디렉터리가 그것인지 확인하세요:

iroute 198.51.100.64 255.255.255.240

OpenVPN의 라우팅된 네트워크 문서 는 두 계층과 그것이 왜 분리되어 있는지 설명합니다. iroute가 없는 커널 경로는 소유자 없이 패킷을 터널로 보내고, OpenVPN은 그것을 버립니다. 커널 경로가 없는 iroute는 패킷을 서버의 기본 경로에 남깁니다. 두 실수 모두 클라이언트 쪽에서는 끊어진 터널처럼 보입니다.

서비스 주소가 사는 곳

위임된 접두사는 터널 자체의 주소와 같은 것이 아닙니다. 원한다면 링크를 사설 공간에서 번호 매기고, 공인 서비스 주소는 서비스가 실제로 실행되는 곳에 두세요.

서비스를 로컬에서 종료하는 Linux 클라이언트에서는 호스트 주소 하나면 충분합니다:

ip address add 198.51.100.70/32 dev lo

접두사가 VM 호스트나 다른 LAN으로 더 라우팅되면 대신 그 하위 경로와 반환 경로를 구성하세요. 블록의 모든 주소를 VPN 클라이언트에 할당할 필요는 없고, 나중에 충돌을 만듭니다.

반환 경로에서 공인 소스를 유지한다

위임된 접두사에서 온 응답은 터널을 통해 나가 공급자의 경로에 도달해야 합니다. 원격 호스트가 자체 ISP를 통해 보내면 소스 주소가 위조된 것처럼 보이고, 공급자나 목적지가 그것을 버립니다. 해결책은 소스 기반 규칙이나 전용 라우팅 테이블 이며, 더 넓은 NAT가 아닙니다. 그것이 없으면 서비스는 터널 피어에서는 작동하고 다른 모든 곳에서는 실패합니다.

진입 서버에서는 넓은 masquerade 규칙이 흔한 원인입니다. 그것은 공인 소스를 서버의 주소로 다시 쓰고, 클라이언트는 실제 주소를 결코 보지 못합니다:

iptables -t nat -S POSTROUTING

NAT를 필요한 사설 VPN 클라이언트로 제한하고 위임된 접두사는 변환하지 마세요. 그다음 기본 거부 전달 체인이 그것을 조용히 버리므로 서버가 접두사를 전혀 전달하는지 확인하세요.

믿기 전에 양방향을 검증하라

검증은 하나가 아니라 네 가지 관찰입니다. 공급자 경로가 도착하는지, 커널이 접두사를 터널로 보내는지, OpenVPN이 올바른 클라이언트에 귀속시키는지, 응답이 공인 소스를 그대로 유지한 채 돌아오는지 확인하세요. 각 관찰에는 자체 명령이 있으므로 실패는 전체 설계가 아니라 한 계층을 가리킵니다. 구성 변경 후마다 이 순서로 실행하세요.

커널에 위임된 주소가 어느 경로를 타는지 물어보고, 요청이 실행되는 동안 터널을 관찰하세요:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

역방향 경로 필터링은 올바른 경로를 무효화할 수 있습니다. 터널과 업링크의 실제 설정을 확인하고, 엄격 모드는 도착한 인터페이스와 소스가 일치하지 않는 트래픽을 거부한다는 것을 기억하세요:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

마지막으로 실패 사례를 시험하세요. 터널을 멈추고 공인 접두사가 일반 업링크로 새지 않는지 확인하세요. VPN을 복원하면 호스트가 여는 포트를 넓히지 않고 서비스가 돌아와야 합니다.