Construction de VPN de passerelle IPsec avec CentOS 8 et openSUSE (Raspberry Pi) --2 Confirmation de connexion VPN StrongSwan

Hypothèses et préparatifs

Article sur la construction du serveur Linux

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

environnement

--Programme IPST: StrongSwan 5.9.0 (compilation des sources) --Récepteur de négociation IPST: Raspberry Pi 3B + / openSUSE 15.1 Leap (aarm64)

supposition

CentOS8.1


# vi /etc/selinux/config

/etc/selinux/config


SELINUX=disabled

CentOS8.1


# reboot

Conditions du serveur

Adresse IP et schéma de construction du réseau

--Passerelle d'origine de la négociation IPTI (à droite de la figure ci-dessous, CentOS 8.1):

Fonctions et versions pour télécharger et installer individuellement les packages (à partir de septembre 2020)

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.

Procédure de travail

Connectez le serveur et le client au VPN

Attribution d'adresses IP dans la zone VPN

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 d'openSUSE (Raspberry Pi), il était facile d'attribuer manuellement une adresse IP à eth1 avec YaST, mais dans le cas de CentOS 8.1 (machine virtuelle Hyper-V), lorsque j'ai essayé de le faire avec Network Manager, cela ne fonctionnait pas. C'était (´ • ̥̥̥ω • ̥̥̥`)

CentOS8.1(Hyper-V/x64)


# nmcli c modify eth1 ipv4.address 192.168.5.1/24
Erreur:Connexion inconnue'eth1'.

J'ai abandonné cette fois et j'ai décidé de copier le fichier de configuration de / etc / sysconfig / network-scripts / de celui de eth0 et de le modifier.

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"changer en
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="eth0"← Adaptateur supplémentaire. ici"eth1"changer en
UUID="daccf09e-f112-4817-8ade-016524d946d5"← Supprimer la ligne elle-même
DEVICE="eth0"← Adaptateur supplémentaire. ici"eth1"changer en
ONBOOT="yes"
IPADDR="192.168.1.18"← Adaptateur supplémentaire. ici"192.168.5.1"changer en
PREFIX="24"
GATEWAY="192.168.1.1"← Supprimer la ligne elle-même
DNS1="192.168.1.1"← Supprimer la ligne elle-même
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 [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 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.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

Cette fois, je l'ai chargé dans Network Manager en utilisant cette méthode stable et j'ai défini l'adresse IP dans eth1. Bien sûr, 192.168.5.0/24 a également été reconnu dans le routage.

D'un autre côté, openSUSE de Raspeye était facile à allouer 192.168.2.1 au nouvel eth1 dans YaST! L'adaptateur ajouté est également attaché d'une manière facile à comprendre! !!

openSUSE15.1(RaspberryPi)


# yast
"Système" -> "Paramètres réseau"
L'adresse IP est 192.168.2.Définir sur 1

YaST・IPアドレス設定前

↓ L'adaptateur réseau USB supplémentaire que j'ai utilisé porte le nom de périphérique "AX88772B", définissez-y l'adresse 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 [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 eth0
       valid_lft forever preferred_lft forever
    inet6 [Adresse IPv6 de la carte réseau depuis le début] 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 [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 eth1
       valid_lft forever preferred_lft forever
    inet6 [Adresse IPv6 de l'adaptateur réseau d'extension] 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

Allouer des zones pare-feu

Puisque la zone par défaut de firewalld est "publique", toutes les règles de firewall-cmd qui ont été ajoutées et modifiées jusqu'à présent sont dans la zone publique, donc la zone publique est eth0 du côté Internet et eth1 du côté de la zone VPN est la zone interne. J'ai décidé d'allouer. C'est la même chose pour CentOS de la machine virtuelle Hyper-V et openSUSE de 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

Connexion par câble LAN du serveur et du client au réseau dans la zone VPN

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 IPsecゲートウェイ以内のVPNに接続する図

Vérification du fonctionnement de la connexion au réseau VPN

Ping passe à ce stade

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

J'ai défini correctement l'adresse IP du VPN, donc j'ai d'abord vérifié avec Ping si le client Ubuntu (192.168.2.2) pouvait passer au serveur Web (192.168.5.2) dans la zone VPN opposée, et cela passait facilement (´ ´). థ ౪ థ)

C'est parce que le firewalld de CentOS 8.1 de la machine virtuelle Hyper-V utilise nftables, j'ai vérifié l'état des nftables, mais il semble que la règle de filtrage de nftables permette toujours le transfert d'ICMP (nftables) Je n'entrerai pas dans les détails ici ...).

Cela ne signifie pas que le Web peut être vu sur la zone VPN à ce stade.

この時点ではIPsec-VPN越しサーバーのwgetは不可 Bien sûr, même wget est devenu "No route". .. ..

Autoriser le transfert firewalld, mais abandonner en raison de l'intégration de CentOS 8.1 nftables

Les paquets tunnelisés par IPsec doivent également ajouter une règle d'autorisation de transfert dans le pare-feu 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 vers 192.168.2.0/24 → 192.168.5.0/24 est ajoutée à la règle, mais dans le cas de firewalld, --direct doit être spécifié. ..

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 transmettre via le VPN.

[192.168.2.0/24 → 192.168.5.0/24 Autorisation HTTP]
# 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 Autorisation HTTPS]
# 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 ports 8080 permettent]
# 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 autorisé]
# 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

[Vérifier]
# 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

Cependant, un problème est survenu là-bas (´ • ̥̥̥ω • ̥̥̥`) Rasppie (open SUSE) a confirmé que les paquets ont été passés des deux côtés de eth0 et eth1 par tcpdump, mais ** Dans CentOS 8.1 de la machine virtuelle Hyper-V, le paquet reçu par eth0 est rejeté (rejeter le filtre interdit .admin). Et le message ICMP est renvoyé au client Ubuntu) **, et wget dit toujours "No route" ...

Bien sûr, j'ai définitivement ajouté une règle de filtrage direct à firewalld avec --direct. J'ai donc étudié les nftables basés sur le pare-feu CentOS 8.1.

J'ai évoqué diverses choses liées aux nftables! (´ • ̥ ̫ • ̥ `) -̗̀ ♡ ̖ -

Peut-être que la table nftables utilisée pour firewalld semble être "inet firewalld", mais la règle de filtre nftables originale utilise "ip filter". J'ai donc utilisé la commande d'opération nftables "nft" pour savoir où se trouve la règle directe ajoutée par l'option --direct avec firewall-cmd.

CentOS8.1(Hyper-V/x64)


[Règles de transfert dans le filtre IP de la table]
# 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)


[Règles de transfert dans le tableau inet firewalld. Emboîté plusieurs fois dans le saut]
# 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 {
        }
}

Le résultat de cette commande est que même si j'ai ajouté une règle avec --direct avec ** firewall-cmd, aucune règle n'est appliquée à la table inet firewalld et elle entre dans le filtre ip. De plus, la règle de transfert dans le filtre ip est ignorée et seule la règle inet firewalld est exécutée, et par conséquent, lorsque je suis la règle de transfert inet firewalld, elle entre dans la règle de rejet de "rejeter avec le type icmpx admin-interdit". Il semble qu'il ait agi en tant que **.

La priorité est certainement que le filtre ip (0) doit être référencé avant inet firewalld (+10), mais si vous ne comprenez pas pourquoi le filtre ip est ignoré et trouvez même un fichier de configuration qui fait référence à la règle principale Ce n'était pas le cas (il est pré-installé dans la version compilée du module et ne peut pas être édité directement avec vi ??).

Probablement, il semble que l'interface directe de nftables et de firewalld ne soit pas compatible pour le moment, donc j'ajoute manuellement une règle de transfert (filter_FWDI_public_allow qui décrit la cible d'autorisation) à la table de inet firewalld avec nft au moment du démarrage de Linux. Il y avait seulement. .. .. (´ • ̥̥̥ω • ̥̥̥`)

Depuis le 7 septembre 2020, la version nftables est v0.9.3 et la version firewalld est 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
        }
}

Vérifiez si vous pouvez accéder au serveur Web

L'incompatibilité entre firewalld et nftables était un frein, mais pour l'instant nftables a décidé d'autoriser manuellement le transfert du pare-feu (´-ε- ｀) si les deux passerelles IPsec pouvaient autoriser le transfert. , J'ai essayé de voir si le client Ubuntu peut accéder au serveur dans le VPN via le VPN.

サーバーアクセス成功

Encore une fois, ** le client Ubuntu est 192.168.2.2, à partir duquel l'écran accède au serveur (192.168.5.2) sur le VPN opposé au-delà du segment de réseau de 192.168.1.0/24 avec tunnel IPsec ** est. J'ai aussi essayé de me connecter avec SSH (˶ ･ ᴗ ･) ੭⚐⚑

Même avec tcpdump, vous pouvez voir que les paquets simples sont tunnelés avec ESP.

Vérification de sécurité

Les paquets sur la passerelle IPsec sont-ils chiffrés? ??

Je pense que c'est le but d'IPsec-VPN. Puisqu'il s'agit d'IPsec, il y a un risque accru d'écoute clandestine s'il est tunnelé en texte brut sans être chiffré à 192.168.1.0/24 en passant par le côté Internet ;;

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

Ouais, c'est crypté! !! (˶ ･ ᴗ ･) ੭ ♡♡

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

Pouvez-vous accéder de l'intérieur de la zone VPN vers l'extérieur? ??

J'ai également vérifié si le client Ubuntu (192.168.2.2) pouvait réellement accéder au segment externe de 192.168.1.0/24.

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

En effet, tous les terminaux de la zone VPN envoient des paquets à la passerelle IPsec, qui est l'entrée du VPN, vers 192.168.1.0/24, ce qui n'est pas autorisé par la passerelle IPsec (192.168.2.0/24 → 192.168.5.0). Seul / 24 est autorisé). Au contraire, même si cela est autorisé, le terminal de 192.168.2.2 → 192.168.1.0/24 enverra le client Ubuntu à la passerelle IPsec comme entrée comme passerelle par défaut, et la route sortante de la passerelle IPsec au terminal cible atteindra. Au retour, au contraire, le terminal en 192.168.1.0/24 ne connaît pas le routage pour revenir à 192.168.2.0/24, donc la communication ne sera possible que si le segment de réseau dans la zone VPN est ajouté à la table de routage. ..

Est-il possible d'accéder à la zone VPN de l'extérieur? ??

Surtout c'est l'endroit le plus inquiétant ... ♆ (⃔ `꒳´ \ *) ⃕ ↝ Cependant, comme mentionné ci-dessus, si le terminal à 192.168.1.0/24 ne connaît pas l'itinéraire vers le VPN, il ne devrait y avoir aucun problème de routage.

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

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

À moins que vous ne disiez à un modem tel que Fretz Optical Aggregation dans 192.168.1.0/24, qui est directement connecté à Internet, le segment vers une telle zone VPN, il est fondamentalement sûr qu'il est peu probable que le VPN soit accessible de l'extérieur. pense. Cependant, je pense que la passerelle IPsec qui divise la zone VPN devrait fermement restreindre à la fois le numéro de port qui devrait être autorisé à passer et la destination / source avec un pare-feu.

Résumé

J'ai essayé de construire une passerelle IPsec avec Raspberry Pi (openSUSE) et CentOS 8.1 de la machine virtuelle Hyper-V avec StrongSwan et vérifié si elle peut répondre à l'utilisation comme IPsec-VPN, mais l'aspect de la prévention des écoutes externes C'est très efficace, mais j'ai senti qu'il faudrait faire attention là où cela ferait mal plus tard si l'accès était correctement autorisé à la zone VPN.

Si possible, les terminaux de la zone externe qui peuvent accéder au VPN sont limités à la passerelle IPsec, et le SSH dans le VPN est également une méthode de clé publique.Il y a toujours une limite si vous ne sélectionnez pas de sécurité complexe, non limitée au pare-feu et IPsec. Je pense ...

Recommended Posts

Construction de VPN de passerelle IPsec avec CentOS 8 et openSUSE (Raspberry Pi) --2 Confirmation de connexion VPN StrongSwan
Construction VPN simple de la passerelle IPsec avec CentOS 8 et openSUSE (Raspberry Pi) --1 Introduction de StrongSwan
Construction VPN simple de la passerelle IPsec avec Ubuntu 20.04 et Raspberry Pi --2 Confirmation de connexion VPN StrongSwan
Construction VPN simple de la passerelle IPsec avec Ubuntu 20.04 et Raspberry Pi ―― 1. StrongSwan introduit
Construire un serveur VPN avec Raspberry Pie
Surveillance des animaux avec Rekognition et Raspberry pi
MQTT Radicon Car avec Arduino et Raspberry
Connexion facile entre Raspberry Pi et AWS IoT
Obtenez la température et l'humidité avec DHT11 et Raspberry Pi
Exemple de programme de connexion Raspberry Pi et AWS IoT
Modifiez et déboguez le code dans Raspberry Pi avec la fonction de connexion SSH de VSCode
Création d'un environnement distribué avec la série Raspberry PI (Partie 4: Création d'un serveur NFS et importation d'un système d'exploitation client)
Enregistrez la température et l'humidité avec systemd sur Raspberry Pi
Apprentissage automatique avec Raspberry Pi 4 et Coral USB Accelerator
Détecter l'état de port du masque avec OpenCV et Raspberry Pi
Résoudre les problèmes liés à l'installation d'OpenCV sur Raspberry Pi et à la capture
Création d'un environnement distribué avec la série Raspberry PI (Partie 7: configuration de la route tftp et test de démarrage pour chaque tarte à la râpe)
GPGPU avec Raspberry Pi
DigitalSignage avec Raspberry Pi
Introduction facile au piratage domestique avec Raspberry Pi et discord.py
Créez une caméra de surveillance WEB avec Raspberry Pi et OpenCV
Débutant Python s'ouvre et se ferme avec Raspberry Pi
Créez des jeux LCD (16x2) avec Raspberry Pi et Python
J'ai essayé de connecter Raspeye et conect + avec l'API Web
Production de système de contrôle de température avec tarte aux framboises et ESP32 (1)
Mesurez et comparez les températures avec Raspberry Pi et générez automatiquement des graphiques