[LINUX] Erstellen Sie ein IPSec-Gateway-VPN mit CentOS 8 und openSUSE (Raspberry Pi) - 2 StrongSwan VPN-Verbindungsbestätigung

Annahmen und Vorbereitungen

Artikel zum Aufbau eines Linux-Servers

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! (˶ ･ ᴗ ･) ੭⚐⚑

Umgebung

--IPST-Programm: StrongSwan 5.9.0 (Quellensammlung) --IPST-Verhandlungsempfänger: Raspberry Pi 3B + / openSUSE 15.1 Leap (aarm64)

Annahme

CentOS8.1


# vi /etc/selinux/config

/etc/selinux/config


SELINUX=disabled

CentOS8.1


# reboot

Serverbedingungen

IP-Adresse und Netzwerkaufbau

--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)

Funktionen und Versionen zum individuellen Herunterladen und Installieren von Paketen (Stand September 2020)

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.

Arbeitsablauf

Verbinden Sie Server und Client mit VPN

IP-Adresszuweisung im VPN-Bereich

Beim letzten Mal hat eth1 gerade einen Netzwerkadapter hinzugefügt, und es wurde noch keine IP-Adresse zugewiesen. Im Fall von openSUSE (Raspberry Pi) war es einfach, eth1 mit YaST manuell eine IP-Adresse zuzuweisen, aber im Fall von CentOS 8.1 (virtuelle Hyper-V-Maschine) funktionierte dies nicht, als ich versuchte, dies mit Network Manager zu tun. Es war (´ • ̥̥̥ω • ̥̥̥`)

CentOS8.1(Hyper-V/x64)


# nmcli c modify eth1 ipv4.address 192.168.5.1/24
Error:Unbekannte Verbindung'eth1'.

Ich habe diesmal aufgegeben und beschlossen, die Einstellungsdatei von / etc / sysconfig / network-scripts / von der von eth0 zu kopieren und zu bearbeiten.

CentOS8.1(Hyper-V/x64)


# cd /etc/sysconfig/network-scripts/
# cp ifcfg-eth0 ifcfg-eth1
# vi ifcfg-eth1

/etc/sysconfig/network-scripts/ifcfg-eth1


TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="none"
DEFROUTE="yes"			← "no"ändern
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"← Zusätzlicher Adapter. Hier"eth1"ändern
UUID="daccf09e-f112-4817-8ade-016524d946d5"← Löschen Sie die Zeile selbst
DEVICE="eth0"← Zusätzlicher Adapter. Hier"eth1"ändern
ONBOOT="yes"
IPADDR="192.168.1.18"← Zusätzlicher Adapter. Hier"192.168.5.1"ändern
PREFIX="24"
GATEWAY="192.168.1.1"← Löschen Sie die Zeile selbst
DNS1="192.168.1.1"← Löschen Sie die Zeile selbst
IPV6_PRIVACY="no"

CentOS8.1(Hyper-V/x64)


# systemctl restart NetworkManager
# 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 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.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

openSUSE15.1(RaspberryPi)


# yast

.168.2.

YaST・IPアドレス設定前

YaST・IPアドレス設定後

openSUSE15.1(RaspberryPi)


# 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 pfifo_fast state UP group default qlen 1000
    link/ether [Andererseits war es für Raspeyes openSUSE einfach, 192.168.2.1 dem neuen eth1 in YaST zuzuweisen! Der hinzugefügte Adapter ist ebenfalls leicht verständlich angebracht! !! "System" -> "Netzwerkeinstellungen" Stellen Sie die IP-Adresse auf 1921 ein. ↓ Der zusätzliche USB-Netzadapter, den ich verwendet habe, hat den Gerätenamen "AX88772B". Stellen Sie daher dort die IP-Adresse ein. ↓ 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 eth0
       valid_lft forever preferred_lft forever
    inet6 [IPv6-Adresse des Netzwerkadapters von Anfang an] scope global dynamic
       valid_lft 14373sec preferred_lft 12573sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 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 eth1
       valid_lft forever preferred_lft forever
    inet6 [IPv6-Adresse des Nebenstellen-Netzwerkadapters] scope link
       valid_lft forever preferred_lft forever

# ip route
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.22
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1

Ordnen Sie Firewall-Zonen zu

Da die Standardzone von firewalld "public" ist, befinden sich alle Regeln von firewall-cmd, die bisher hinzugefügt und bearbeitet wurden, in der öffentlichen Zone, sodass die öffentliche Zone auf der Internetseite eth0 und eth1 auf der Seite des VPN-Bereichs die interne Zone ist. Ich entschied mich zuzuteilen. Dies gilt auch für CentOS der virtuellen Hyper-V-Maschine und openSUSE of Raspeye.

# firewall-cmd --zone=public --change-interface=eth0 --permanent
# firewall-cmd --zone=internal --change-interface=eth1 --permanent
# firewall-cmd --reload

# firewall-cmd --get-active-zones
internal
  interfaces: eth1
public
  interfaces: eth0

LAN-Kabelverbindung von Server und Client zum Netzwerk im VPN-Bereich

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.

Überprüfung des VPN-Netzwerkverbindungsbetriebs

Ping geht an dieser Stelle vorbei

IPアドレスが適切なだけでもPingは通る

Ich habe die IP-Adresse für VPN richtig eingestellt, also habe ich zuerst mit Ping geprüft, ob der Ubuntu-Client (192.168.2.2) an den Webserver (192.168.5.2) im gegenüberliegenden VPN-Bereich übergeben werden kann, und er hat problemlos übergeben (´´). థ ౪ థ)

Dies liegt daran, dass die Firewall von CentOS 8.1 der virtuellen Hyper-V-Maschine nftables verwendet. Ich habe den Status von nftables überprüft, aber es scheint, dass die Filterregel von nftables immer die Übertragung von ICMP (nftables) ermöglicht. Ich werde hier nicht auf Details eingehen ...).

Das bedeutet nicht, dass das Web zu diesem Zeitpunkt über den VPN-Bereich sichtbar ist.

この時点ではIPsec-VPN越しサーバーのwgetは不可 Natürlich ist auch wget zu "No route" geworden. .. ..

Firewall-Übertragung zulassen, aber aufgrund der Integration von CentOS 8.1-Nftables aufgeben

Von IPSec getunnelte Pakete müssen außerdem eine Weiterleitungsberechtigungsregel in der Firewall des IPSec-Gateways hinzufügen. Daher habe ich den Port geöffnet, an dem Server und Client im VPN kommunizieren. Da hier 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 firewalld muss jedoch --direct 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 ihn über das VPN übertragen.

[192.168.2.0/24 → 192.168.5.0/24 HTTP-Berechtigung]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 80 -j ACCEPT
[192.168.2.0/24 → 192.168.5.0/24 HTTPS-Berechtigung]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 443 -j ACCEPT
[192.168.2.0/24 → 192.168.5.0/24 Port 8080 erlauben]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8080 -j ACCEPT
[192.168.2.0/24 → 192.168.5.0/24 Port 8443 erlaubt]
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8443 -j ACCEPT

[Überprüfen]
# firewall-cmd --direct --get-all-rules
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 80 -j ACCEPT
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 443 -j ACCEPT
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8080 -j ACCEPT
ipv4 filter FORWARD_direct 1 -s 192.168.2.0/24 -p tcp -d 192.168.5.0/24 --dport 8443 -j ACCEPT

Dort ist jedoch ein Problem aufgetreten (´ • ̥̥̥ω • ̥̥̥`) Rasppie (offene SUSE) bestätigte, dass Pakete von tcpdump auf beiden Seiten von eth0 und eth1 übergeben wurden. ** In CentOS 8.1 der virtuellen Hyper-V-Maschine wird das von eth0 empfangene Paket abgelehnt (Filter ".admin verboten" ablehnen). Die ICMP-Nachricht wird an den Ubuntu-Client zurückgegeben) ** und wget sagt immer noch "Keine Route" ...

Natürlich habe ich Firewalld mit --direct definitiv eine direkte Filterregel hinzugefügt. Also habe ich nftables untersucht, die mit CentOS 8.1 firewalld zurückbasiert sind.

Ich habe auf verschiedene Dinge im Zusammenhang mit nftables hingewiesen! (´ • ̥ ̫ • ̥ `) -̗̀ ♡ ̖ -

Möglicherweise scheint die für firewalld verwendete nftables-Tabelle "inet firewalld" zu sein, aber die ursprüngliche nftables-Filterregel verwendet "ip filter". Also habe ich den nftables-Operationsbefehl "nft" verwendet, um herauszufinden, wo sich die direkte Regel befindet, die durch die Option --direct mit firewall-cmd hinzugefügt wurde.

CentOS8.1(Hyper-V/x64)


[Weiterleitungsregeln im Tabellen-IP-Filter]
# nft list chain ip filter FORWARD
table ip filter {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 80 counter packets 0 bytes 0 accept
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 443 counter packets 0 bytes 0 accept
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8080 counter packets 0 bytes 0 accept
                meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8443 counter packets 0 bytes 0 accept
        }
}

CentOS8.1(Hyper-V/x64)


[Weiterleitungsregeln in der Tabelle inet firewalld. Mehrmals im Sprung verschachtelt]
# nft list chain inet firewalld filter_FORWARD
table inet firewalld {
        chain filter_FORWARD {
                type filter hook forward priority filter + 10; policy accept;
                ct state { established, related } accept
                ct status dnat accept
                iifname "lo" accept
                ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable
                jump filter_FORWARD_IN_ZONES_SOURCE
                jump filter_FORWARD_IN_ZONES
                jump filter_FORWARD_OUT_ZONES_SOURCE
                jump filter_FORWARD_OUT_ZONES
                ct state { invalid } drop
                reject with icmpx type admin-prohibited
        }
}
# nft list chain inet firewalld filter_FORWARD_IN_ZONES
table inet firewalld {
        chain filter_FORWARD_IN_ZONES {
                iifname "eth0" goto filter_FWDI_public
                iifname "eth1" goto filter_FWDI_internal
                goto filter_FWDI_public
        }
}
# nft list chain inet firewalld filter_FWDI_public
table inet firewalld {
        chain filter_FWDI_public {
                jump filter_FWDI_public_pre
                jump filter_FWDI_public_log
                jump filter_FWDI_public_deny
                jump filter_FWDI_public_allow
                jump filter_FWDI_public_post
                meta l4proto { icmp, ipv6-icmp } accept
        }
}
# nft list chain inet firewalld filter_FWDI_public_deny
table inet firewalld {
        chain filter_FWDI_public_deny {
        }
}
# nft list chain inet firewalld filter_FWDI_public_allow
table inet firewalld {
        chain filter_FWDI_public_allow {
        }
}

Das Ergebnis dieses Befehls ist, dass, obwohl ich eine Regel mit --direct mit ** firewall-cmd hinzugefügt habe, keine Regel auf die inet firewalld-Tabelle angewendet wird und in den IP-Filter eingeht. Außerdem wird die Weiterleitungsregel im IP-Filter ignoriert und nur die Inet-Firewall-Regel ausgeführt. Wenn ich der Inet-Firewall-Weiterleitungsregel folge, wird daher die Ablehnungsregel "Ablehnen mit ICMPX-Typ admin-verboten" eingegeben. Es scheint, dass es als ** gehandelt hat.

Die Priorität ist sicherlich, dass der IP-Filter (0) vor inet firewalld (+10) referenziert werden sollte, aber wenn Sie nicht verstehen, warum der IP-Filter ignoriert wird, und sogar eine Konfigurationsdatei finden, die auf die Hauptregel verweist Es war nicht (im kompilierten Modul vorinstalliert und kann nicht direkt mit vi bearbeitet werden ??).

Wahrscheinlich scheint es, dass die direkte Schnittstelle von nftables und firewalld im Moment inkompatible Fehler sind. Daher füge ich der Tabelle von inet firewalld mit nft beim Linux-Start manuell eine Übertragungsregel (filter_FWDI_public_allow, die das Berechtigungsziel beschreibt) hinzu Es gab nur. .. .. (´ • ̥̥̥ω • ̥̥̥`)

Ab dem 7. September 2020 ist die nftables-Version v0.9.3 und die firewalld-Version v0.8.0.

CentOS8.1(Hyper-V/x64)


# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 80 accept
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 443 accept
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8080 accept
# nft add rule inet firewalld filter_FWDI_public_allow meta l4proto tcp ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8443 accept

# nft list chain inet firewalld filter_FWDI_public_allow
table inet firewalld {
        chain filter_FWDI_public_allow {
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 80 accept
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 443 accept
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8080 accept
                meta nfproto ipv4 ip saddr 192.168.2.0/24 ip daddr 192.168.5.0/24 tcp dport 8443 accept
        }
}

Überprüfen Sie, ob Sie auf den Webserver zugreifen können

Die Inkompatibilität zwischen firewalld und nftables war ein Nachteil, aber vorerst entschieden sich nftables, die Weiterleitung der Firewall manuell zuzulassen (´-ε- ｀), wenn beide IPSec-Gateways die Weiterleitung zulassen konnten. Ich habe versucht zu sehen, ob der Ubuntu-Client über das VPN auf den Server im VPN zugreifen kann.

サーバーアクセス成功

Wiederum ist ** Ubuntu-Client 192.168.2.2, von dem aus der Bildschirm über das Netzwerksegment 192.168.1.0/24 mit IPSec-Tunneling auf den Server (192.168.5.2) über das Netzwerksegment 192.168.1.0/24 zugreift. ist. Ich habe auch versucht, eine Verbindung mit SSH herzustellen (˶ ･ ᴗ ･) ੭⚐⚑

Selbst mit tcpdump können Sie sehen, dass einfache Pakete mit ESP getunnelt werden.

Sicherheitskontrolle

Sind Pakete über das IPSec-Gateway verschlüsselt? ??

Ich denke, das ist der Punkt von IPsec-VPN. Da es sich um IPSec handelt, besteht ein erhöhtes Risiko des Abhörens, wenn es im Klartext getunnelt wird, ohne dass es bei 192.168.1.0/24 verschlüsselt wird und über das Internet übertragen wird.

パケットがIPsec暗号化されている！

Ja, es ist verschlüsselt! !! (˶ ･ ᴗ ･) ੭ ♡♡

Ich habe versucht, mit dem Client vom Server aus auf die Seite zuzugreifen, ohne "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ" Ich tat! !!

Können Sie von innerhalb des VPN-Bereichs nach außen zugreifen? ??

Ich habe auch geprüft, ob der Ubuntu-Client (192.168.2.2) tatsächlich auf das äußere Segment von 192.168.1.0/24 zugreifen kann.

セキュア外部は接続不可 セキュア外部は接続不可

Dies liegt daran, dass alle Terminals im VPN-Bereich Pakete an das IPSec-Gateway senden, das der Eingang zum VPN ist, an 192.168.1.0/24, was vom IPSec-Gateway nicht zulässig ist (192.168.2.0/24 → 192.168.5.0). Nur / 24 ist erlaubt). Im Gegenteil, selbst wenn dies zulässig ist, sendet das Terminal von 192.168.2.2 → 192.168.1.0/24 den Ubuntu-Client als Eingang als Standardgateway an das IPSec-Gateway, und die ausgehende Route vom IPSec-Gateway zum Zielterminal wird erreicht. Auf der Rückfahrt hingegen kennt das Terminal in 192.168.1.0/24 das Routing für die Rückkehr zu 192.168.2.0/24 nicht, sodass eine Kommunikation nur möglich ist, wenn das Netzwerksegment im VPN-Bereich zur Routing-Tabelle hinzugefügt wird. ..

Ist es möglich, von außen auf den VPN-Bereich zuzugreifen? ??

Besonders dies ist der besorgniserregendste Ort ... ♆ (⃔ `꒳´ \ *) ⃕ ↝ Wie oben erwähnt, sollte es jedoch keine Probleme beim Routing geben, wenn das Terminal unter 192.168.1.0/24 die Route zum VPN nicht kennt.

VPN外部からVPN内部にアクセスしようとすると…

192.168.1.0/24というVPN外部から、192.168.2.0/24と192.168.5.0/24の2つのVPN領域内のサーバーやクライアントに、PingやWebアクセスしようとしても、接続されることはないことを確認。

Wenn Sie einem Modem wie Fretz Optical Aggregation in 192.168.1.0/24, das direkt mit dem Internet verbunden ist, das Segment zu einem solchen VPN-Bereich nicht mitteilen, ist es grundsätzlich sicher, dass es unwahrscheinlich ist, dass von außen auf das VPN zugegriffen wird. Überlegen. Ich denke jedoch, dass das IPSec-Gateway, das den VPN-Bereich unterteilt, sowohl die Portnummer, die passieren darf, als auch das Ziel / die Quelle mit einer Firewall stark einschränken sollte.

Zusammenfassung

Ich habe versucht, ein IPSec-Gateway mit Raspberry Pi (openSUSE) und CentOS 8.1 der virtuellen Hyper-V-Maschine mit StrongSwan zu erstellen, und habe überprüft, ob es die Verwendung als IPSec-VPN erfüllen kann, aber den Aspekt der Verhinderung des externen Abhörens Es ist sehr effektiv, aber ich war der Meinung, dass es notwendig sein würde, vorsichtig zu sein, wo es später wehtun würde, wenn der Zugriff auf den VPN-Bereich ordnungsgemäß gestattet würde.

Wenn möglich, sind die Terminals im externen Bereich, die auf das VPN zugreifen können, auf das IPSec-Gateway beschränkt, und das SSH im VPN ist auch eine Methode mit öffentlichem Schlüssel. Es gibt immer noch eine Beschränkung, wenn Sie keine komplexe Sicherheit auswählen, nicht beschränkt auf Firewall und IPSec. Ich denke ...

Recommended Posts

Erstellen Sie ein IPSec-Gateway-VPN mit CentOS 8 und openSUSE (Raspberry Pi) - 2 StrongSwan VPN-Verbindungsbestätigung
Einfacher VPN-Aufbau eines IPSec-Gateways mit CentOS 8 und openSUSE (Raspberry Pi) --1 Einführung von StrongSwan
Einfacher VPN-Aufbau eines IPSec-Gateways mit Ubuntu 20.04 und Raspberry Pi - 2 StrongSwan VPN-Verbindungsbestätigung
Einfacher VPN-Aufbau eines IPSec-Gateways mit Ubuntu 20.04 und Raspberry Pi ―― 1. StrongSwan eingeführt
Aufbau eines VPN-Servers mit Raspberry Pie
Haustierüberwachung mit Rekognition und Raspberry pi
MQTT Radicon Car mit Arduino und Himbeere
Einfache Verbindung zwischen Raspberry Pi und AWS IoT
Holen Sie sich Temperatur und Luftfeuchtigkeit mit DHT11 und Raspberry Pi
Beispiel für ein Raspberry Pi und AWS IoT-Verbindungsprogramm
Bearbeiten und debuggen Sie den Code in Raspberry Pi mit der SSH-Verbindungsfunktion von VSCode
Erstellen einer verteilten Umgebung mit der Raspberry PI-Serie (Teil 4: Erstellen eines NFS-Servers und Importieren eines Client-Betriebssystems)
Notieren Sie Temperatur und Luftfeuchtigkeit mit systemd auf Raspberry Pi
Maschinelles Lernen mit Raspberry Pi 4 und Coral USB Accelerator
Ermitteln Sie den Tragezustand der Maske mit OpenCV und Raspberry Pi
Fehlerbehebung bei der Installation von OpenCV auf Raspberry Pi und der Erfassung
Erstellen einer verteilten Umgebung mit der Raspberry PI-Serie (Teil 7: Einstellung der TFTP-Route und Starttest für jeden Raspetorte)
GPGPU mit Raspberry Pi
DigitalSignage mit Raspberry Pi
Einfache Einführung in Home Hack mit Raspberry Pi und discord.py
Erstellen Sie eine WEB-Überwachungskamera mit Raspberry Pi und OpenCV
Python-Anfänger öffnet und schließt die ineinandergreifende Kamera mit Raspberry Pi
Erstellen Sie LCD-Spiele (16x2) mit Raspberry Pi und Python
Ich habe versucht, Raspeye und conect + mit der Web-API zu verbinden
Herstellung eines Temperaturregelungssystems mit Himbeerkuchen und ESP32 (1)
Messen und vergleichen Sie Temperaturen mit Raspberry Pi und generieren Sie automatisch Diagramme