Tunnellisation d'une IP publique vers une machine distante


8

J'ai un serveur Linux A avec un bloc de 5 adresses IP publiques, 8.8.8.122/29. Actuellement, 8.8.8.122est affecté à eth0et 8.8.8.123est affecté à eth0:1.

J'ai une autre machine Linux B dans un emplacement distant, derrière NAT. Je voudrais mettre en place un tunnel entre les deux afin que B puisse utiliser l'adresse IP 8.8.8.123comme adresse IP principale.

OpenVPN est probablement la réponse, mais je n'arrive pas à comprendre comment configurer les choses ( topology subnetou topology p2ppourrait être approprié. Ou devrais-je utiliser un pont Ethernet?). La sécurité et le chiffrement ne sont pas une grande préoccupation à ce stade, donc GRE serait bien aussi - la machine B proviendra d'une adresse IP connue et peut être authentifiée sur cette base.

Comment puis-je faire ceci? Quelqu'un peut-il suggérer une configuration OpenVPN, ou une autre approche, qui pourrait fonctionner dans cette situation? Idéalement, il serait également capable de gérer plusieurs clients (par exemple, partager les quatre adresses IP de rechange avec d'autres machines), sans laisser ces clients utiliser des adresses IP auxquelles ils n'ont pas droit.


Quels sont les pare-feu aux deux emplacements?
Robert

1
J'espère que vous venez de créer ces adresses, plutôt que de travailler chez Google. Sinon, vous ne pourrez pas utiliser leur espace d'adressage.
Michael Hampton

Robert: A est un serveur Linux avec quelques iptablesrègles simples . B est derrière un NAT qui est un autre serveur Linux en cours d'exécution shorewall.
Jim Paris

Michael: Oui, j'ai changé les trois premiers octets en 8 pour les obscurcir, mais toujours indiquer qu'ils sont publics. Désolé, Google.
Jim Paris

1
Pour référence future, nous avons un RFC pour cela .
Michael Hampton

Réponses:


7

J'ai fini par utiliser le pontage Ethernet. Beaucoup d'exemples extrêmement verbeux à parcourir en ligne, mais cela s'avère assez facile:

Tout d'abord, sur A , a /etc/network/interfacesété changé de:

auto eth0
iface eth0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121

à:

auto br0
iface br0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121
    pre-up openvpn --mktun --dev tap0
    bridge_ports eth0 tap0
    bridge_fd 3

afin de relier eth0(la vraie interface WAN) avec tap0(une nouvelle interface tunnel) au démarrage.

Ensuite, sur A , exécutez le serveur openvpn avec:

openvpn --dev tap0

Sur B , connectez-vous avec:

openvpn --remote 8.8.8.122 --dev tap0 --route-gateway 8.8.8.121 \
        --redirect-gateway def1 --ifconfig 8.8.8.123 255.255.255.248

C'est la configuration super simple que je cherchais, et cela fonctionne - B est maintenant accessible au public au 8.8.8.123, et les connexions sortantes proviennent de la même adresse.

Ajouter la sécurité ( --secret, --tls-server, etc.) au besoin, bien sûr.


Agréable! Je vais essayer ça. Avez-vous trouvé un moyen de configurer cela: "sans laisser ces clients utiliser des adresses IP auxquelles ils n'ont pas droit"?
Bastian

Je n'ai pas dérangé dans ma configuration (qui était temporaire), mais j'imagine que vous pourriez le faire avec des ebtables.
Jim Paris

Très utile. Une question: que dois-je changer dans la configuration A si j'ai besoin de router deux IP de A: A => B et A => C (où C est un autre hôte)? Dois-je configurer un autre pont?
frhack

2
Ouais. Ajoutez une autre pre-up openvpnligne pour créer tap1aussi, ajoutez tap1à bridge_portset exécutez une autre instance de openvpn avec openvpn --dev tap1.
Jim Paris

Que diriez-vous si vous vouliez rendre la passerelle A locale via B afin que tout système sur le LAN puisse utiliser B et affecter la passerelle par défaut distante et utiliser des adresses IP publiques?
Areeb Soo Yasir

1

Vous allez avoir du mal, je pense. La plupart des pare-feu auront du mal à acheminer le trafic OpenVPN si les deux côtés du VPN sont dans le même sous-réseau.

Si vous essayez de router pour l'accès public, je déplacerais les deux serveurs vers des sous-réseaux différents à partir de vos adresses publiques, puis j'utiliserais des adresses IP virtuelles (1 à 1 Nat) pour les connecter. Pour connecter les deux sites, OpenVPN fonctionnerait ou un tunnel IP-Sec.

IP virtuelles: http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

Site à site: http://doc.pfsense.org/index.php/VPN_Capability_IPsec

Modifier en fonction des commentaires:

J'installerais personnellement pfSense sur la boîte A et lui donnerais le port que vous vouliez pour son WAN. Ensuite, configurez un serveur OpenVPN sur un sous-réseau local (qui est prêt à fonctionner dans l'interface Web pfSense) et configurez l'autre machine avec une adresse IP virtuelle pointant vers son adresse IP OpenVPN locale. Cela vous donnerait plus de place pour l'expansion plus tard (ajoutez plus de machines avec des adresses IP virtuelles, transférez logiquement des ports spécifiques à différents serveurs, disposez vraiment d'une configuration LAN / WAN / DMZ complète avec OpenVPN pour l'accès virtuel. Sans oublier que vous auriez un un routeur complet pour qu'il soit probablement plus sûr.


Je ne comprends pas comment les pare-feu intermédiaires sont impliqués; ils ne seront certainement pas à la recherche à l' intérieur des paquets OpenVPN entre A et B . Pour la configuration OpenVPN elle-même, je m'attendais à ce que quelque chose comme push "route 50.7.19.122 255.255.255.255 net_gateway"cela garantisse que les données VPN soient toujours transmises sur le réseau normal.
Jim Paris

Pour être clair, je veux créer un tunnel directement entre A et B , pas sur des pare-feu séparés à chaque extrémité.
Jim Paris

1
Mais lorsque l'ordinateur A veut router vers l'ordinateur B, il ne saura pas s'il doit utiliser le WAN (avec vos adresses IP publiques), le LAN (avec son adresse IP statique) ou OpenVPN (également avec vos adresses IP publiques) car ils sont tous même sous-réseau. B à A devrait cependant fonctionner.
Robert

1
Il y a aussi cela, je l'ai fait fonctionner mais pas avec des adresses IP publiques. Je pense que les IP virtuelles seront bien meilleures de toute façon. openvpn.net/index.php/open-source/documentation/miscivers/…
Robert

"Pour être clair, je veux créer un tunnel directement entre A et B, pas sur des pare-feu séparés à chaque extrémité." Vous allez devoir ouvrir un port quelque part pour un serveur OpenVPN
Robert
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.