Tunneln einer öffentlichen IP mit OpenVPN

Oct 08 2020

Ich habe einige Schwierigkeiten, eine öffentliche IP mit OpenVPN auf einen Remote-VPS zu tunneln. Ich habe einen Linux-Server mit einem Block von 32 öffentlichen IP-Adressen 192.0.2.160/27mit dem Namen Server 1 sowie eine weitere öffentliche IP-Adresse, an die eth0auf demselben Server gebunden ist : 203.0.113.43.

Ich habe einen anderen Linux-Computer, Server 2 , hinter NAT woanders. Ich möchte in der Lage sein, einen OpenVPN-Server auf Server 1 so einzurichten, dass der Client, Server 2 , eine IP-Adresse im 192.0.2.160/27Subnetz verwenden kann.

Ich habe die folgende Anleitung zu ServerFault befolgt und versuche, Ethernet-Bridging mit OpenVPN mithilfe von TAP zu verwenden.

Auf Server 1 sieht die Netzwerkkonfiguration ungefähr so aus (ich habe die IPs zu Dokumentationszwecken ersetzt - siehe RFC5737):

Server 1 / etc / network / interfaces

auto eth0

auto br0
iface br0 inet static
     address 203.0.113.43
     netmask 255.255.255.0
     gateway 203.0.113.1
     pre-up openvpn --mktun --dev tap0
     bridge_ports eth0 tap0
     bridge_fd 3

Ich führe dann openvpn auf Server 1 mit aus openvpn --dev tap0und wenn ich auf Server 2 Folgendes eingebe :

openvpn --remote 203.0.113.43 --dev tap0 --route-gateway 203.0.113.1 \
--redirect-gateway def1 --ifconfig 192.0.2.160 255.255.255.224

Eine Verbindung wird hergestellt, aber ich kann 192.0.2.160auf keinem anderen Computer als auf Server 2 pingen (kann dies nicht einmal auf Server 1 tun ).

Ich glaube definitiv, dass mir etwas fehlt, aber ich kann es nicht herausfinden.

Ich werde auch hinzufügen, dass ich die IPv4-Paketweiterleitung /etc/sysctl.confauf Server 1 aktiviert habe .

Wenn jemand diese Konfiguration vervollständigen oder eine alternative Methode vorschlagen kann, um dies zu erreichen, wäre dies sehr dankbar.

[EDIT 1 - Danke AB]

Der Hosting-Anbieter ist Heficed und erklärt hier, wie zusätzliche öffentliche IPs (unter CentOS) hinzugefügt werden: https://kb.heficed.com/en/articles/2854555-adding-ip-to-your-network-interface

Antworten

A.B Oct 13 2020 at 03:42

Nach diesem KB-Artikel von Heficed :

Wenn Sie einen Server mit einer Haupt-IP gekauft und zusätzliche IPs zugewiesen haben, werden zusätzliche IPs statisch auf Ihren Haupt-IPs weitergeleitet , sodass beim Konfigurieren der IPs auf Ihrer Netzwerkkarte keine Gateway- oder Broadcast-Adressen erforderlich sind.

Die Haupt-IP-Adresse von Server1 wird verwendet, um andere IP-Adressen zu erreichen. Man kann sich also vorstellen, dass der Router von Server1 (wenn es auch Linux wäre) wahrscheinlich eine ähnliche Einstellung hat:

ip route add 192.0.2.160/27 via 203.0.113.43

Es ist nicht erforderlich, eth0 zu überbrücken, und eine Überbrückung führt zu zusätzlichen Schwierigkeiten für das Ziel. Die Komplexität, die erforderlich ist, um am Ende ohnehin ungewöhnliches Routing zu verwenden (immer noch ein Gateway zu verwenden, das nicht Teil des IP-LAN ist), lohnt sich nicht.

So kann die Netzwerkkonfiguration von server1 vereinfacht werden in:

auto eth0
iface eth0 inet static
    address 203.0.113.43
    netmask 255.255.255.0
    gateway 203.0.113.1

Achten Sie beim Ändern der Konfiguration auf Verbindungsverlust. Sie sollten über einen Remote- / virtuellen Konsolenzugriff als Backup verfügen.

Im Folgenden finden Sie Lösungen ohne Überbrückung der Hauptschnittstelle des Hosts mithilfe von Routing, entweder mit TAP (möglicherweise kann Server1 beispielsweise einen DHCP-Server für Server2 ausführen ) oder mit TUN.

Um die 32 IP-Adressen verfügbar zu halten, werden einige ungewöhnliche Routeneinstellungen verwendet, für die OpenVPN einige Probleme aufweist. Daher wird ein Skript verwendet, um die --ifconfigOption zu überschreiben . Wenn man 3 IP-Adressen aus dem / 32-Pool opfert: eine, die Server1 zugewiesen ist, sowie 192.0.2.160 und 192.0.2.191, die als Netzwerk- und Broadcast-Netzwerkadressen verwendet werden, wird alles einfach und es ist kein zusätzliches Skript erforderlich.

Anmerkungen:

Um Server1 als IPv4-Router zu konfigurieren , der für eine der unten beschriebenen Methoden erforderlich ist, können Sie diesen Eintrag beispielsweise auskommentieren / hinzufügen in /etc/sysctl.confoder /etc/sysctl.d/<somefile>:
```
net.ipv4.ip_forward=1
```
Führen Sie dies auch als root aus, nachdem die Konfiguration geändert wurde:
```
sysctl -w net.ipv4.ip_forward=1
```
Befehle entwickeln sich:
```
openvpn --mktun --dev {tap,tun}0
```
kann durch eine der folgenden ersetzt werden:
```
ip tuntap add dev tap0 mode tap
ip tuntap add dev tun0 mode tun
```
ip tuntap erschien "nur" im Jahr 2009 .

ZAPFHAHN

Einfache Methode

Um wirklich einfach zu bleiben, wird keine permanente TAP-Schnittstelle verwendet (Sie können diese Konfiguration jederzeit ändern).

Es werden 192.0.2.160, 192.0.2.161 ( Server1 zugewiesen ) und 192.0.2.191 aus dem Pool verbraucht .

Server1 :

openvpn --dev tap --ifconfig 192.0.2.161 255.255.255.224

Server2 :
```
openvpn --remote 203.0.113.43 --dev tap --ifconfig 192.0.2.162 255.255.255.224 --route-gateway 192.0.2.161 --redirect-gateway def1
```
Sie können auch eine der 28 verbleibenden IP-Adressen zwischen 192.0.2.163 und 192.0.2.190 zu Server2 auf einer seiner Schnittstellen hinzufügen (z. B.: Zuweisen auf Tap0 oder Zuweisen auf Lo, damit sie auch vorher nicht verschwindet ):
```
ip address add 192.0.2.163/32 dev lo
```

Methode, um alle 32 Adressen verwendbar zu halten

Server1 :

Fügen Sie eine TAP-Schnittstelle hinzu /etc/network/interfaces, um die OpenVPN-Konfiguration von Server1 zu vereinfachen :
```
auto tap0
iface tap0 inet static
    pre-up ip tuntap add dev tap0 mode tap || :
    address 10.10.10.10/32
    up ip route add 192.0.2.160/27 dev tap0
    down ip link delete dev tap0
```
Führen Sie aus, ifup tap0wenn Sie gerade fertig sind, und führen Sie Folgendes aus:
```
openvpn --dev tap0
```
Server2 :

eine ausführbare Datei namens haben up-cmd-server2.sh(die darin verwendeten Variablen werden von OpenVPN geerbt):
```
#!/bin/sh

ip address add "$ifconfig_local"/32 dev "$dev"
ip link set dev "$dev" up ip route add "$route_vpn_gateway"/32 dev "$dev"
```
und Renn:
```
openvpn --remote 203.0.113.43 --dev tap --ifconfig-noexec --ifconfig 192.0.2.160 255.255.255.255 --route-gateway 10.10.10.10 --redirect-gateway def1 --script-security 2 --up up-cmd-server2.sh
```
Die IP-Adresse 10.10.10.10 wird niemals außerhalb des VPN angezeigt, und selbst innerhalb wird nur bei Fehlern angezeigt , z. B. im Ergebnis eines Traceroute- Befehls oder natürlich, wenn Server1 über das VPN und nicht über das VPN erreicht wird Internet. Eine von außen ausgeführte Traceroute würde Fehler ab 203.0.113.43 anzeigen.

Was ist mit Containern oder VMs auf Server1 ?

Wenn ein Teil des Datenverkehrs über das VPN geleitet werden soll und ein Teil des Datenverkehrs lokal sein soll, kann tap0 oben erneut zu einer Brücke versklavt werden. Diese Bridge ist weiterhin für ein geroutetes LAN vorgesehen: Sie wird eth0 nicht überbrücken, und 10.10.10.10/32 sollte ihr anstelle von tap0 zugewiesen werden . Daneben gelten weiterhin die obigen Einstellungen und Erklärungen. Container können veth- Links und VMs zusätzliche TAP-Links verwenden, die alle auf der Bridge versklavt sind.

TUN

TAP ist nützlich, wenn Eigenschaften im Zusammenhang mit der Verwendung von Ethernet über den Tunnel benötigt werden, z. B. dass Server1 einen DHCP-Server für Server2 ausführt oder den LAN-Verkehr über das VPN gemeinsam nutzt (TUN kann auch für die gemischte Verwendung mit ein paar weiteren Routenänderungen und Proxy-ARP verwendet werden. aber die Konfigurationskomplexität ist es dann wahrscheinlich nicht wert). Andernfalls kann TUN mit weniger Overhead verwendet werden (z. B. IP-Paket kleiner als Ethernet-Frame und ohne ARP). Da es sich bei beiden Fällen um Routing handelt, sind die Einstellungen fast dieselben wie oben.