☰

OpenBSD 5.5에서 OpenVPN을 통한 LAN 라우팅

tag-icon • tag-icon routing openbsd openvpn pf
OpenBSD 5.5에서 OpenVPN을 통한 LAN 라우팅

LAN이 인터넷으로 터널링할 수 있도록 OpenVPN 게이트웨이를 구성하고 있습니다. 게이트웨이는 PC 엔진 APU 플랫폼에서 OpenBSD 5.5-stable amd64를 실행합니다.

LAN에는 re1, re2및 ral0인터페이스가 포함되어 있습니다. 또한 vether0로컬 네트워크의 호스트 도 포함됩니다 192.168.2.0/24. 이러한 인터페이스는 연결되어 bridge0공용 게이트웨이, 서브넷 및 DHCP를 제공합니다 dhcpd.

VPN이 설정되어 tun0활성화되었습니다. 게이트웨이 자체에서는 정상적으로 VPN에 액세스할 수 있습니다.

문제는 기본적으로 호스트가 192.168.2.0/24VPN에 액세스하기 위해 기본 주소를 사용한다는 것입니다. 로컬 네트워크를 에 있는 VPN 네트워크로 변환하려면 NAT가 필요합니다 10.0.1.0/24.

다음 구성을 시도했습니다 pf.conf.

# pf.conf -- 10.0.1.10 is my tun0 gateway
set skip on lo
block return
pass in quick on { vether0 re1 re2 ral0 } from 192.168.2.0/24 to !10.0.0.0/8 nat-to 10.0.1.10
pass

다음 규칙을 사용하여 비슷한 결과를 얻었습니다.

# pf.conf
...
pass in from any nat-to 10.0.1.10
pass out from tun0 to any

tun0이를 통해 LAN 트래픽이 소스 주소를 통과 10.0.1.10하고 트래픽을 적절한 호스트로 반환할 수 있습니다. 새로운 문제는 반환 트래픽이 여전히 올바르게 라우팅되지 않는 것 같다는 것입니다.

예를 들어, 모든 LAN 호스트에서 ping 8.8.8.8및 ping을 보낼 수 있지만 google.com첫 번째 응답은 항상 tun0반환 인터페이스를 통해 삭제됩니다. dig, nslookup, 및 traceroute같은 도구는 ping느리게 실행되고 예상보다 훨씬 오래 걸리는 경우가 많습니다. 일부 트래픽이 계속해서 발생하고 있지만 브라우저 및 기타 애플리케이션을 사용할 수 없습니다.

tcpdump손실 증명:

# 192.168.2.103 is a LAN host
# 74.125.131.139 is google.com

# on ral0
20:59:35.668251 192.168.2.103 > 74.125.131.139: icmp: echo request <-- no reply
20:59:40.651184 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:40.736748 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:41.656101 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:41.741251 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:42.661071 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:42.802410 74.125.131.139 > 192.168.2.103: icmp: echo reply

# on tun0
20:59:35.668359 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:35.764052 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- here's the missing reply, it didn't get to ral0
20:59:40.651221 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:40.736721 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- but the of the replies rest did
20:59:41.656138 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:41.741226 74.125.131.139 > 10.0.1.10: icmp: echo reply
20:59:42.661107 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:42.802372 74.125.131.139 > 10.0.1.10: icmp: echo reply

이것이 NAT 문제임이 거의 확실하다는 것을 알고 있지만 pf.conf여러 번 구성을 시도한 후에도 트래픽을 전달하는 올바른 방법을 찾을 수 없습니다.

DD-WRT를 사용할 때의 iptables구성은 다음과 같습니다.

iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept

하지만 이것을 로 "포팅"하는 방법을 잘 모르겠습니다 pf. 어떤 조언이라도 대단히 감사하겠습니다!

답변1

이것이 문제인 것으로 판명되었습니다 pf.conf. 공부에 좀 더 시간을 투자하세요OpenBSD PF NAT페이지에서 트래픽이 인터페이스를 올바르게 통과하도록 허용하는 다음 규칙으로 이동했습니다 tun0.

# /etc/pf.conf
pass out on tun0 inet from 192.168.2.0/24 to any flags S/SA nat-to (tun0) round-robin

이는 기본적으로 다음과 같이 작동합니다. 로컬 네트워크에서 트래픽을 전달하고, 대상은 모든 주소 tun0(특히 IPv4)에 있으며, 보고 플래그를 지정 syn하고 ackNAT를 사용하여 아웃바운드 NAT를 수행합니다 tun0. 대괄호는 인터페이스가 주소를 변경할 때 규칙이 자동으로 업데이트됨을 (tun0)나타냅니다 . pfVPN이 여러 피어를 지원하고 장애 조치를 수행하는 경우 이러한 일이 발생할 수 있으므로 규칙 세트를 수동으로 다시 로드할 필요가 없습니다.

몇 시간 동안OpenBSD PF 필터링이 페이지는 규칙을 구체화하는 데 도움이 되었습니다.

# /etc/pf.conf
pass out on $vpn_if inet proto { $protos } from $lan_net to any flags S/SA modulate state nat-to ($vpn_if) round-robin
pass in  on $vpn_if inet proto { $protos } from $vpn_gw  to any flags S/SA modulate state

이 modulate state플래그를 사용하면 pf더 강력한 초기 시퀀스 번호를 대체할 수 있으며, 이는 네트워크의 특정 운영 체제를 보호하는 데 도움이 될 수 있습니다.

현재 게이트웨이는 훌륭하게 작동하고 있으며 더 복잡한 pf.conf구성을 작업 중입니다.

관련 정보