La dernière fois, nous avons construit un environnement IPsec-VPN en compilant la source de StrongSwan, mais cette fois, vérifions si nous pouvons réellement nous connecter au VPN! (˶ ・ ᴗ ・) ੭⚐⚑
--Programme IPST: StrongSwan 5.9.0 (compilation des sources) --Récepteur de négociation IPST: Raspberry Pi 3B + / Raspberry Pi OS (version 2020/08) (armhf (v7), 32 bits)
--Passerelle d'origine de la négociation IPTI (à droite de la figure ci-dessous, Ubuntu 20.04):
Côté Internet (eth0): 192.168.1.18
Côté de la zone VPN (eth1): 192.168.5.1
Segment de réseau:
Connexion Internet possible: 192.168.1.0/24 --Raspberry Pi (côté réception de la négociation à gauche de la figure) Segment sécurisé: 192.168.2.0/24 --Ubuntu 20.04 (appelant en négociation répertorié comme "CentOS 8" à droite de la figure) Segment sécurisé: 192.168.5.0/24
Terminaux qui se connectent au VPN: --Client (Ubuntu 20.04): 192.168.2.2 (appartient à 192.168.2.0/24)
Serveur Web Linux (CentOS 8.1): 192.168.5.2 (appartient à 192.168.5.0/24)
Domaine IPST lié:
Section de raccordement: Entre 192.168.1.22 et 192.168.1.18
Coopération VPN: connexion VPN de 192.168.2.0/24 à 192.168.5.0/24
Ici, nous allons essayer ** 192.168.2.2 client Ubuntu pour établir une connexion VPN au serveur Web Linux 192.168.5.2 **. Le serveur et le client connectés au VPN ne se connecteront que dans la portée du VPN et ne se connecteront pas à Internet.
Les autres packages requis sont installés à l'aide des commandes de package standard de la distribution (dnf, apt, etc.) et n'ont pas besoin d'être téléchargés individuellement.
Pour le téléchargement, vous pouvez accéder au site officiel, le télécharger à partir de là et le transférer par FTP, ou vous pouvez l'obtenir avec wget si vous connaissez l'URL du fichier à télécharger, mais la méthode d'acquisition est omise.
La dernière fois, eth1 vient d'ajouter une carte réseau et aucune adresse IP n'a encore été attribuée. Dans le cas du système d'exploitation Raspberry Pi, j'ai dû ajouter /etc/dhcpcd.conf manuellement. .. Bien sûr, dhcpcd.conf a à la fois la passerelle par défaut et le serveur DNS spécifiés, donc si vous en spécifiez plusieurs, le classement du réseau sera confondu, de sorte que seule l'adresse IP est décrite dans le nouveau eth1.
Article de référence:
RaspberryPiOS(2020.08)
# vi /etc/dhcpcd.conf
/etc/dhcpcd.conf(RaspberryPiOS)
[Ajout des informations d'interface suivantes à la dernière ligne]
#interface eth1
interface eth1
static ip_address=192.168.2.1/24
noipv6
RaspberryPiOS(2020.08)
# reboot
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [Adresse MAC de l'adaptateur réseau depuis le début] brd ff:ff:ff:ff:ff:ff
inet 192.168.1.22/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 [Adresse IPv6 de la carte réseau depuis le début] scope global dynamic noprefixroute
valid_lft 14373sec preferred_lft 12573sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [Adresse MAC de l'adaptateur réseau d'extension] brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.5.255 scope global noprefixroute eth1
valid_lft forever preferred_lft forever
inet6 [Adresse IPv6 de l'adaptateur réseau d'extension] scope link noprefixroute
valid_lft forever preferred_lft forever
# ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.22 metric 100
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1 metric 101
Le fichier de configuration de l'adresse IP dépend trop de la distribution et il est difficile si vous n'y êtes pas habitué ٩ (. ›‹. ♡) ۶ J'ai défini une adresse IP pour eth1. Bien sûr, 192.168.2.0/24 a également été reconnu dans le routage.
D'un autre côté, avec Hyper-V Ubuntu, vous pouvez le définir sur l'écran GUI au lieu de SSH, vous pouvez donc simplement spécifier l'adresse et le masque de réseau là-bas et enregistrer les paramètres ٩ (. ›‹..) ۶
Ubuntu20.04(Hyper-V/x64)
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [Adresse MAC de l'adaptateur réseau depuis le début] brd ff:ff:ff:ff:ff:ff
inet 192.168.1.18/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 [Adresse IPv6 de la carte réseau depuis le début] scope global temporary dynamic
valid_lft 14043sec preferred_lft 12243sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [Adresse MAC de l'adaptateur réseau d'extension] brd ff:ff:ff:ff:ff:ff
inet 192.168.5.1/24 brd 192.168.5.255 scope global noprefixroute eth1
valid_lft forever preferred_lft forever
inet6 [Adresse IPv6 de l'adaptateur réseau d'extension] scope link noprefixroute
valid_lft forever preferred_lft forever
# ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18 metric 100
192.168.5.0/24 dev eth1 proto kernel scope link src 192.168.5.1 metric 101
Inutile de dire ceci. Connectez le serveur et le client avec un câble LAN et définissez l'adresse IP manuellement (le serveur DHCP n'est pas dans la zone VPN, vous devez donc le configurer manuellement)
Comme indiqué dans "Conditions du serveur", attribuez des adresses IP avec la connexion par câble LAN comme indiqué dans la figure ci-dessous. Bien entendu, dans le cas d'une machine virtuelle, il ne vous reste plus qu'à affecter un commutateur virtuel.
--Connectez le client Ubuntu à Raspeye (192.168.2.0/24). Définissez l'adresse IP sur 192.168.2.2 --Connectez le serveur Web Linux à la machine virtuelle Hyper-V (192.168.5.0/24). Définissez l'adresse IP sur 192.168.5.2
L'écran est pour CentOS + openSUSE, mais même dans le cas de l'utilisation d'Ubuntu cette fois, lorsque j'ai vérifié si le client (192.168.2.2) pouvait se connecter au serveur Web (192.168.5.2) dans la zone VPN opposée, cela passait facilement (´ ´). థ ౪ థ)
Après tout, même dans le cas de la passerelle IPsec d'Ubuntu, il semble que le Web ne soit pas vu au-dessus de la zone VPN à ce moment-là.
Bien sûr, wget devrait également être "No route"
Les paquets tunnelisés par IPsec doivent également ajouter une règle d'autorisation de transfert dans ufw de la passerelle IPsec, j'ai donc ouvert le port où le serveur et le client dans le VPN communiquent. Ici, puisque le client est 192.168.2.2 et le serveur 192.168.5.2, l'autorisation de transfert pour 192.168.2.0/24 → 192.168.5.0/24 est ajoutée à la règle, mais dans le cas de ufw, il est nécessaire de spécifier la route.
Les ports utilisés par le serveur Web sont 80, 443, 8080, 8443, qui est le Web, donc bien sûr, si vous entrez la commande suivante, la passerelle IPsec doit la transférer via le VPN.
[192.168.2.0/24 → 192.168.5.0/24 Autorisation HTTP]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 80 proto tcp
[192.168.2.0/24 → 192.168.5.0/24 Autorisation HTTPS]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 443 proto tcp
[192.168.2.0/24 → 192.168.5.0/24 ports 8080 permettent]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 8080 proto tcp
[192.168.2.0/24 → 192.168.5.0/24 Port 8443 autorisé]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 8443 proto tcp
[Vérifier]
# ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] 30303/tcp ALLOW IN 192.168.1.0/24
…(Omission)…
[10] 192.168.5.0/24 80/tcp ALLOW FWD 192.168.2.0/24
[11] 192.168.5.0/24 443/tcp ALLOW FWD 192.168.2.0/24
[12] 192.168.5.0/24 8080/tcp ALLOW FWD 192.168.2.0/24
[13] 192.168.5.0/24 8443/tcp ALLOW FWD 192.168.2.0/24
…(Omission)…
référence:
Dans CentOS 8.1 de la machine virtuelle Hyper-V, firewalld et direct ne sont pas compatibles (en particulier, il semble que l'enregistrement avec nftables échoue), donc [Problème que la règle de transfert ne peut pas être transférée même si elle est enregistrée dans firewalld. Se produit](https://qiita.com/kazumi75kitty/items/f5a33abda9f8edd5c47f#firewalld%E3%81%AE%E8%BB%A2%E9%80%81%E8%A8%B1%E5%8F%AF% E3% 82% 92% E3% 81% 99% E3% 82% 8B% E3% 81% 8Ccentos-81% E3% 81% AEnftables% E3% 81% AE% E9% 80% A3% E5% 8B% 95% E3% 81% AB% E3% 83% 8F% E3% 83% 9E% E3% 81% A3% E3% 81% A6% E6% 96% AD% E5% BF% B5), mais Ubuntu 20.04 Et Raspberry Pi OS (version 2020/08) ufw n'a pas encore rencontré un tel problème, et comme Debian OS recommandera nftables à l'avenir, si le problème des nftables et des règles de transfert n'est pas résolu tôt, CentOS C'est peut-être une deuxième danse, mais ...
Si les deux passerelles IPsec permettaient le transfert, j'ai essayé de voir si le client pouvait accéder au serveur dans le VPN via le VPN.
Cet écran de réussite est l'écran de CentOS + openSUSE, mais il fonctionne bien sur Ubuntu! !!
Après tout, même dans le cas d'Ubuntu, le paquet confirme le cryptage dans le tunnel IPsec comme indiqué dans l'écran ci-dessous (˶ ・ ᴗ ・) ੭ ♡♡
J'ai essayé d'accéder à la page à partir du serveur avec le client sans crypter "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ..." avec HTTPS, mais quand je l'ai récupéré par tunneling entre les passerelles IPsec, il était crypté. J'ai fait! !!
Avec StrongSwan, le système d'exploitation Raspberry Pi et Ubuntu 20.04 de la machine virtuelle Hyper-V ont également construit une passerelle IPsec et confirmé qu'elle répondait à l'utilisation d'IPsec-VPN. Après tout, j'ai trouvé que les mesures de sécurité sont les mêmes que dans le cas de CentOS, mais il semble qu'il y ait encore des problèmes de compatibilité avec nftables ufw et firewalld à l'avenir ... ⸝⸝ᵕᵕ⸝⸝
Recommended Posts