Ich konfiguriere ein OpenVPN-Gateway, um einen LAN-Zugriff auf das Internet über den Tunnel zu ermöglichen. Das Gateway läuft mit OpenBSD 5.5-stable amd64 auf der PC Engines APU-Plattform.
Das LAN enthält die Schnittstellen re1, re2, und ral0. Es enthält außerdem , vether0auf denen das lokale 192.168.2.0/24Netzwerk gehostet wird. Diese Schnittstellen sind unter verknüpft, bridge0um ein gemeinsames Gateway, Subnetz und DHCP über bereitzustellen dhcpd.
Das VPN wird eingerichtet und tun0geöffnet. Das Gateway selbst kann problemlos auf das VPN zugreifen.
Das Problem besteht darin, dass die Hosts standardmäßig mit ihren nativen 192.168.2.0/24Adressen auf das VPN zugreifen. NAT wird benötigt, um das lokale Netzwerk in das VPN-Netzwerk zu übersetzen 10.0.1.0/24.
Ich habe die folgenden pf.confKonfigurationen ausprobiert:
# 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
Mit diesen Regeln hatte ich ähnliche Ergebnisse:
# pf.conf
...
pass in from any nat-to 10.0.1.10
pass out from tun0 to any
tun0Dadurch kann LAN-Verkehr mit der Quelladresse passieren 10.0.1.10und der Rückverkehr wird an den entsprechenden Host zurückgeleitet. Das neue Problem besteht darin, dass der Rückverkehr anscheinend immer noch nicht richtig geroutet wird.
Ich kann beispielsweise von jedem LAN-Host aus 8.8.8.8und anpingen google.com, die erste Antwort wird jedoch IMMER zwischen tun0und der Rückschnittstelle unterbrochen. Tools wie dig, nslookup, traceroute, und pingsind im Allgemeinen träge und brauchen viel länger als sie sollten. Obwohl noch etwas Datenverkehr durchläuft, sind Browser und andere Anwendungen unbrauchbar.
tcpdumpden Verlust nachweisen:
# 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
Ich weiß, dass es sich mit ziemlicher Sicherheit um ein NAT-Problem handelt, pf.confaber nach so vielen Konfigurationsversuchen habe ich Schwierigkeiten, die richtige Vorgehensweise für die Weiterleitung des Datenverkehrs zu finden.
Als ich DD-WRT und verwendet habe iptables, war dies meine Konfiguration:
iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept
Ich bin mir allerdings nicht sicher, wie ich das auf "portieren" kann pf. Für Vorschläge bin ich sehr dankbar!
Antwort1
Dies stellte sich als pf.confProblem heraus. Etwas mehr Zeit wurde für das Studium derOpenBSD PF NATtun0Seite führte mich zu der folgenden Regel, die den Datenverkehr ordnungsgemäß durch die Schnittstelle passieren ließ :
# /etc/pf.conf
pass out on tun0 inet from 192.168.2.0/24 to any flags S/SA nat-to (tun0) round-robin
Dies bedeutet im Wesentlichen: Leiten Sie den Verkehr aus dem lokalen Netzwerk, der für eine beliebige Adresse bestimmt ist, an weiter tun0, insbesondere IPv4, achten Sie nur auf die Flags synund ackund führen Sie ausgehendes NAT mit durch tun0. Die Klammern um (tun0)weisen pfdarauf hin, dass die Regel automatisch aktualisiert werden soll, wenn die Schnittstelle ihre Adresse ändert. Dies kann vorkommen, wenn Ihr VPN mehrere Peers unterstützt und Sie ein Failover durchführen, sodass ein manuelles Neuladen des Regelsatzes unnötig wird.
Einige Zeit auf derOpenBSD PF-FilterungSeite hat mir geholfen, die Regel zu verfeinern:
# /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
Das modulate stateFlag ermöglicht pfden Ersatz durch eine stärkere Initial Sequence Number, die zum Schutz einiger Betriebssysteme im Netzwerk beitragen kann.
Das Gateway funktioniert jetzt einwandfrei und ich bin dabei, komplexere pf.confKonfigurationen vorzunehmen.