Raspberry VPN GW / Iptables - Zugriff VPN ins LAN verbieten

[JoSed]

Hallo Allerseits,

ich verwende meinen Raspberry (Squid Proxy, WLANAP) als OpenVPN Gateway um auf amerikanische Streaming Angebote a la Netflix zuzugreifen. Soweit so gut funktioniert auch alles, wenn der OpenVPN Tunnel aufgebaut ist, kann ich per Proxy (Squid) oder WLAN auf die US Dienste zugreifen. (Dienste wie "wieistmeineip.de" zeigen mir die US WAN IP Adresse).
(Anmerkerung: IP des Raspberry, in die Proxy Einstellungen des Browsers eintragen oder halt Tablet per WLAN mit dem AP des Raspberries verbinden)

Jetzt zu meinem eigentlichen Problem, da ich den OpenVPN Server in den USA nicht selber administriere, mache ich mir schon etwas sorgen, jemand könnte vom USA Server durch den VPN Tunnel auf meinen PI oder noch schlimmer auf mein lokales Netz zugreifen! Ich vermute per Iptables müsste ich das Ganze blockieren können, wobei nicht zuviel, da ja der VPN Tunnel aufgebaut werden muss.

Meine IPTables Regeln sehen im Moment so aus:

Code: Alles auswählen

*nat
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
*filter
-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A FORWARD -i wlan0 -o tun0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT

Meine Netzwerkstruktur sieht in etwa so aus:

Code: Alles auswählen

                          +-------------------------+
               (public IP)|                         |
  {INTERNET}=============={     Router              |
                          |                         |
                          |         LAN switch      |
                          +------------+------------+
                                       | (192.168.100.1)
                                       |
                                       |              +-----------------------+
                                       |              |                       |
                                       |              |        OpenVPN        |  eth0: 192.168.100.10/32
                                       +--------------{eth0                   |  tun0: 10.242.33.30/32, GW: 10.242.33.29
                                       |              |                       |
                                       |              |           {tun0}      |
                                       |              +-----------------------+
                                       |
                              +--------+-----------+
                              |                    |
                              |  Other LAN clients |
                              |                    |
                              |   192.168.100.0/24 |
                              |   (internal net)   |
                              +--------------------+

Ich hoffe, Ihr aus der DF-Gemeinde könnt mir hierbei helfen.

Vielen Dank im Voraus.

Gruß
JoSed

[Cae]

Wenn die FOWARD-Policy dann noch auf DROP steht, sollte das LAN wasserdicht sein. Wobei ich da -m state --state verwenden wuerde; zumindest kann ich gerade nicht den besonderen Unterschied zu --ctstate erkennen. Das Framework dahinter ist wahrscheinlich dasselbe, zumindest kann ich auf einer Maschine, wo nur --state verwendet wird, die bestehenden erkannten Verbindungen trotzdem mit conntrack -L (aus conntrack) auslesen. Vermutlich ist -m state --state einfach ein kleineres Subset von -m conntrack.

Fuer den Host selbst ist dann noch etwas wie

Code: Alles auswählen

-A INPUT  -i tun0 -m state ! --state     RELATED,ESTABLISHED -j DROP
-A OUTPUT -o tun0 -m state ! --state NEW,RELATED,ESTABLISHED -j DROP

noetig, damit er selbst (z.B. ein lokaler Proxy-Dienst) ueber den Tunnel rausfunken kann und die Antworten darauf auch bekommt, aber sonst ein eventuell laufender sshd nicht erreichbar ist.

Willkommen im Forum!

Gruss Cae

[JoSed]

Hallo Cae,

wenn du es so sagst, stehen keine Policies auf DROP. Ich glaube, ich hatte es mal probiert, war aber kläglich gescheitert.
Die Ausgabe per "iptables -L" lautet: (die im 1. Post genannten Regeln wurden schon angewendet)

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Müsste dann meine kompletten Regeln so aussehen?

Code: Alles auswählen

sudo iptables -F
sudo iptables -P FORWARD DROP
sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT  -i tun0 -m state ! --state     RELATED,ESTABLISHED -j DROP
sudo iptables -A OUTPUT -o tun0 -m state ! --state NEW,RELATED,ESTABLISHED -j DROP

Schönen Abend
JoSed

[Cae]

Die Ausgabe per "iptables -L" lautet:

Da ist die u.a. interessante Tabelle -t nat nicht dabei, daher bevorzuge ich den iptables-save/ip6tables-save-Output, wie du ihn im Eingangspost hattest.

Müsste dann meine kompletten Regeln so aussehen?

Ja, das sieht gut aus so. (oder man nimmt halt iptables-restore, vielleicht in Kombination mit iptables-persistent, anstatt von 500 iptables(8)-Aufrufen... aber darum geht's gerade nicht )

Gruss Cae

[JoSed]

Guten Abend Cae,

jap, das mit dem ganzen iptables Aufrufen war schon klar, ich hatte es nur kurz eben schnell probiert, da ich keine Zeit mehr hatte.

Jetzt sieht es so aus:

Code: Alles auswählen

*filter
-F INPUT
-F OUTPUT
-F FORWARD

-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT

-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A FORWARD -i wlan0 -o tun0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i tun0 -m state ! --state RELATED,ESTABLISHED -j DROP
-A OUTPUT -o tun0 -m state ! --state NEW,RELATED,ESTABLISHED -j DROP
COMMIT

*nat
-A POSTROUTING -o tun0  -j MASQUERADE
COMMIT

Nachmals vielen Dank für deine Hilfe

Viele Grüße
JoSed

[Cae]

Ja, das sollte so tun. Falls es Probleme gibt, ist wahrscheinlich ein Debugging per -j LOG sinnvoll nach dem Schema

Code: Alles auswählen

-A INPUT -i tun0 -m state ! --state RELATED,ESTABLISHED -j LOG --log-prefix="tun0-IN-drop-"
-A INPUT -i tun0 -m state ! --state RELATED,ESTABLISHED -j DROP

(effizienter waere es, eine eigene Tabelle anzulegen und den Check auf "von tun0 und bestehende Verbindung" nur einmal zu machen). Die Lognachrichten tauchen im dmesg auf und werden normalerweise auch in's Syslog geschrieben. Die Form ist etwas gewoehnungsbeduerftig, aber exakt.

Gruss Cae