터널을 통해 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/24주소를 사용하여 VPN에 액세스한다는 것입니다. 로컬 네트워크를 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첫 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
이는 본질적으로 다음과 같습니다. 의 모든 주소, 특히 IPv4로 향하는 로컬 네트워크의 트래픽을 전달하고 및 플래그 tun0만 확인 하고 를 사용하여 아웃바운드 NAT를 수행합니다 . 주위의 괄호는 인터페이스가 주소를 변경할 때 규칙을 자동으로 업데이트하도록 지시합니다 . 이는 VPN이 여러 피어를 지원하고 장애 조치를 수행하는 경우 발생할 수 있으므로 규칙 세트를 수동으로 다시 로드할 필요가 없습니다.synacktun0(tun0)pf
잠시 동안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구성을 진행하고 있습니다.