Letztes Mal haben wir eine IPSec-VPN-Umgebung erstellt, indem wir die Quelle von StrongSwan kompiliert haben, aber dieses Mal überprüfen wir, ob wir tatsächlich eine Verbindung zum VPN herstellen können! (˶ ・ ᴗ ・) ੭⚐⚑
--IPST-Programm: StrongSwan 5.9.0 (Quellensammlung)
IPST-Verhandlungsempfangs-Gateway (links in der Abbildung unten, Raspberry Pi):
Internet-Seite (eth0): 192.168.1.22
VPN-Bereichsseite (eth1): 192.168.2.1
IPTI Negotiation Originator Gateway (rechts in der Abbildung unten, Ubuntu 20.04):
Internet-Seite (eth0): 192.168.1.18
VPN-Bereichsseite (eth1): 192.168.5.1
Netzwerksegment:
Internetverbindung möglich: 192.168.1.0/24
Himbeer-Pi (Empfangsseite der Verhandlung links in der Abbildung) Sicheres Segment: 192.168.2.0/24 --Ubuntu 20.04 (Absender mit "CentOS 8" rechts in der Abbildung verhandeln) Sicheres Segment: 192.168.5.0/24
--Terminals, die eine Verbindung zu VPN herstellen: --Client (Ubuntu 20.04): 192.168.2.2 (gehört zu 192.168.2.0/24) --Linux Web Server (CentOS 8.1): 192.168.5.2 (gehört zu 192.168.5.0/24)
Hier werden wir versuchen, ** 192.168.2.2 Ubuntu-Client, um eine VPN-Verbindung zum 192.168.5.2 Linux-Webserver herzustellen **. Sowohl der mit dem VPN verbundene Server als auch der Client stellen nur innerhalb des VPN-Bereichs eine Verbindung her und stellen keine Verbindung zum Internet her.
Andere erforderliche Pakete werden mit den Standardpaketbefehlen der Distribution (dnf, apt usw.) installiert und müssen nicht einzeln heruntergeladen werden.
Zum Herunterladen können Sie auf die offizielle Website zugreifen, von dort herunterladen und per FTP übertragen oder mit wget abrufen, wenn Sie die URL der Download-Datei kennen, die Erfassungsmethode jedoch weggelassen wurde.
Beim letzten Mal hat eth1 gerade einen Netzwerkadapter hinzugefügt, und es wurde noch keine IP-Adresse zugewiesen. Im Fall von Raspberry Pi OS musste ich /etc/dhcpcd.conf manuell hinzufügen. .. In dhcpcd.conf sind natürlich sowohl das Standard-Gateway als auch der DNS-Server angegeben. Wenn Sie also mehr als einen angeben, wird das Netzwerkranking verwirrt, sodass nur die IP-Adresse im neu eingerichteten eth1 beschrieben wird.
Referenzartikel:
RaspberryPiOS(2020.08)
# vi /etc/dhcpcd.conf
/etc/dhcpcd.conf(RaspberryPiOS)
[Die folgenden Schnittstelleninformationen wurden zur letzten Zeile hinzugefügt]
#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 [MAC-Adresse des Netzwerkadapters von Anfang an] 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 [IPv6-Adresse des Netzwerkadapters von Anfang an] 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 [MAC-Adresse des Nebenstellen-Netzwerkadapters] 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 [IPv6-Adresse des Nebenstellen-Netzwerkadapters] 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
Die IP-Adresseinstellungsdatei ist zu verteilungsabhängig und es ist schwierig, wenn Sie sich nicht daran gewöhnen. ٩ (. ›‹. ♡) ۶ Ich habe eine IP-Adresse für eth1 festgelegt. Natürlich wurde auch 192.168.2.0/24 im Routing erkannt.
Auf der anderen Seite können Sie mit Hyper-V Ubuntu es auf dem GUI-Bildschirm anstelle von SSH einstellen, sodass Sie dort einfach die Adresse und die Netzmaske angeben und die Einstellungen ٩ (. ›‹. ♡) ۶ speichern können
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 [MAC-Adresse des Netzwerkadapters von Anfang an] 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 [IPv6-Adresse des Netzwerkadapters von Anfang an] 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 [MAC-Adresse des Nebenstellen-Netzwerkadapters] 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 [IPv6-Adresse des Nebenstellen-Netzwerkadapters] 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
Unnötig zu sagen. Verbinden Sie den Server und den Client mit einem LAN-Kabel und stellen Sie die IP-Adresse manuell ein (der DHCP-Server befindet sich nicht im VPN-Bereich, Sie müssen ihn also manuell einstellen).
Weisen Sie, wie unter "Serverbedingungen" gezeigt, IP-Adressen mit der LAN-Kabelverbindung zu, wie in der folgenden Abbildung gezeigt. Bei einer virtuellen Maschine müssen Sie natürlich nur einen virtuellen Switch zuweisen.
Der Bildschirm ist für CentOS + openSUSE, aber selbst bei der Verwendung von Ubuntu dieses Mal, als ich prüfte, ob der Client (192.168.2.2) im gegenüberliegenden VPN-Bereich an den Webserver (192.168.5.2) übergeben werden konnte, ging er problemlos über (´´). థ ౪ థ)
Selbst im Fall des IPSec-Gateways von Ubuntu scheint das Web zu diesem Zeitpunkt nicht über den VPN-Bereich gesehen zu werden.
Natürlich sollte wget auch "No route" sein.
Von IPSec getunnelte Pakete müssen außerdem eine Weiterleitungsberechtigungsregel in ufw des IPSec-Gateways hinzufügen, sodass ich den Port geöffnet habe, an dem Server und Client in VPN kommunizieren. Da der Client 192.168.2.2 und der Server 192.168.5.2 ist, wird der Regel die Übertragungsberechtigung für 192.168.2.0/24 → 192.168.5.0/24 hinzugefügt. Im Fall von ufw muss jedoch die Route angegeben werden.
Die vom Webserver verwendeten Ports sind 80, 443, 8080, 8443, dh das Web. Wenn Sie also den folgenden Befehl eingeben, sollte das IPSec-Gateway über das VPN weiterleiten.
[192.168.2.0/24 → 192.168.5.0/24 HTTP-Berechtigung]
# 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 HTTPS-Berechtigung]
# 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 Port 8080 erlauben]
# 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 erlaubt]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 8443 proto tcp
[Überprüfen]
# ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] 30303/tcp ALLOW IN 192.168.1.0/24
…(Unterlassung)…
[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
…(Unterlassung)…
Referenz:
In CentOS 8.1 der virtuellen Hyper-V-Maschine sind Firewalld und Direct nicht kompatibel (insbesondere scheint die Registrierung bei nftables nicht erfolgreich zu sein). [Problem, dass die Übertragungsregel nicht übertragen werden kann, selbst wenn sie in Firewalld registriert ist. Tritt auf](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), aber Ubuntu 20.04 Und Raspberry Pi OS (Version 2020/08) ufw ist noch nicht auf ein solches Problem gestoßen, und da Debian OS in Zukunft nftables empfehlen wird, wenn das Problem von nftables und Übertragungsregeln nicht frühzeitig gelöst wird, CentOS Es mag ein zweiter Tanz sein, aber ...
Wenn beide IPSec-Gateways die Übertragung zuließen, habe ich versucht zu prüfen, ob der Client über das VPN auf den Server im VPN zugreifen kann.
Dieser Erfolgsbildschirm ist der Bildschirm für CentOS + openSUSE, funktioniert aber unter Ubuntu tatsächlich gut! !!
Schließlich bestätigt das Paket auch im Fall von Ubuntu die Verschlüsselung im IPSec-Tunnel, wie im folgenden Bildschirm gezeigt (˶ ・ ᴗ ・) ੭ ♡♡
Ich habe versucht, mit dem Client vom Server aus auf die Seite zuzugreifen, ohne "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ" Ich tat! !!
Wir haben auch ein IPSec-Gateway unter Raspberry Pi OS und Ubuntu 20.04, einer virtuellen Hyper-V-Maschine mit StrongSwan, erstellt und bestätigt, dass es die Verwendung als IPSec-VPN erfüllt. Ich habe festgestellt, dass die Sicherheitsmaßnahmen dieselben sind wie im Fall von CentOS, aber es scheint, dass es auch in Zukunft Probleme mit der Kompatibilität mit nftables ufw und firewalld gibt ... ⸝⸝ᵕᵕ⸝⸝
Recommended Posts