macOS Sequoia et VPN : comment créer un kill switch système et configurer Network Extension

Introduction

Dans ce guide pas à pas, vous configurerez un kill switch système fiable pour VPN sur macOS Sequoia et comprendrez le fonctionnement des éléments clés de l'API Network Extension. Nous irons du choix du protocole et du client à la création de règles au niveau système grâce au filtre PF, et, si vous le souhaitez, nous aborderons aussi une intégration avancée via Network Extension. En fin de parcours, vous bénéficierez d'une connexion prévisible sans fuite de trafic en dehors du VPN, même en cas de coupures inattendues. Ce guide s'adresse aux débutants mais inclut des sections avancées pour ceux qui veulent approfondir les mécanismes.

Une fois tous les étapes réalisées, vous serez capable de : configurer un client VPN sur macOS Sequoia, importer un fichier de configuration prêt à l'emploi, activer la protection contre les fuites DNS, créer et tester un kill switch système avec PF, automatiser l'activation et la désactivation du filtre, et éventuellement tester un exemple minimal avec l'API Network Extension.

Ce guide convient à : propriétaires de Mac sous macOS Sequoia (à jour en 2026), débutants en sécurité, développeurs souhaitant comprendre les principes, et tous ceux qui veulent garantir un blocage du trafic hors VPN.

Ce qu'il faut savoir avant : manipulations de base des Préférences Système, savoir copier-coller des commandes dans le Terminal, compréhension d'une adresse IP et d'un port. C'est suffisant. Les subtilités de l'API seront expliquées clairement et efficacement.

Durée estimée : la configuration de base du VPN et du kill switch prendra 60 à 90 minutes, plus 30 minutes pour automatisation et vérifications. Réservez 60 minutes supplémentaires pour la partie avancée sur Network Extension si vous avez un compte développeur Apple.

Préparations préalables

Avant de commencer, assurez-vous d'avoir tout le nécessaire. Nous préparerons le système, choisirons le client et la configuration, vérifierons la version macOS et créerons un point de restauration des paramètres réseau importants.

Outils et accès requis

• Mac sous macOS Sequoia (15.x ou supérieur).
• Droits d’administrateur sur l’appareil (pour configurer PF et installer les clients).
• Fichier de configuration pour le protocole choisi (WireGuard, OpenVPN, IKEv2). Cela peut être un .conf pour WireGuard, un .ovpn pour OpenVPN ou des paramètres pour IKEv2.
• Adresse IP et port du serveur VPN. Il est préférable d'avoir l'IP et pas seulement un nom de domaine, pour éviter une dépendance à un DNS externe au moment de l’établissement de connexion.
• Accès internet actif durant la configuration.

Exigences système

• macOS Sequoia 15.x (vérifiez : menu Apple → À propos de ce Mac → Aperçu).
• Au moins 200 Mo libres sur le disque pour clients et logs.
• Connexions sortantes ouvertes vers votre serveur VPN (ports selon protocole : pour WireGuard généralement UDP 51820 ; OpenVPN UDP 1194 ou TCP 443 par défaut ; IKEv2 UDP 500 et 4500).

Téléchargements et installations

• WireGuard pour macOS ou, pour OpenVPN, Tunnelblick/Viscosity ; pour IKEv2, le client intégré à macOS suffit.
• Éditeur de texte pour modifier les configs (par exemple TextEdit intégré ou tout autre).

Sauvegarde

Les modifications réseau touchent les paramètres système. Avant de commencer, enregistrez l’état actuel. Notez les serveurs DNS utilisés, les interfaces actives et la route par défaut.

1. Ouvrez le Terminal.
2. Exécutez la commande scutil --dns. Copiez la section principale DNS dans un fichier texte.
3. Lancez ifconfig et route -n get default. Sauvegardez la sortie pour référence.
4. Créez un point de restauration Time Machine si vous utilisez ce système.

Astuce : Notez l’adresse IP et le port du serveur VPN dans une note. Ces infos seront utiles pour les règles PF afin d’autoriser le trafic sortant uniquement vers le serveur VPN lorsque tout le reste est bloqué.

Concepts de base

Pour faciliter la lecture, clarifions rapidement les termes clés avec des définitions simples, sans théorie inutile.

• VPN — un tunnel chiffré entre votre ordinateur et un serveur VPN distant. Tout votre trafic peut passer par ce tunnel.
• Kill switch — un mécanisme qui bloque tout trafic réseau si le VPN se déconnecte pour une raison quelconque. C’est une protection contre les fuites.
• PF (Packet Filter) — le filtre de paquets intégré à macOS. Il vous permet de définir des règles pour autoriser ou bloquer les connexions, indépendamment des applications.
• Interface utun — une interface réseau virtuelle créée par le client VPN. Par exemple utun0. Tous les paquets VPN chiffrés transitent par cette interface.
• API Network Extension — le framework Apple pour développer des clients VPN, filtres de contenu et proxies. Permet de gérer le tunnel et les réglages réseau par programmation.
• On-Demand — règles déterminant quand et comment le VPN se connecte automatiquement (par exemple sur tous les réseaux sauf les réseaux de confiance), et comment il réagit aux pertes de connexion.
• Fuite DNS — lorsque les requêtes DNS sortent directement sur internet, en dehors du VPN, exposant vos domaines et potentiellement votre IP.

Astuce : Si vous rencontrez des termes inconnus plus loin dans le guide, revenez ici. Comprendre ce qu’est une interface utun et PF facilitera la mise en place du kill switch.

Étape 1 : Choisir le protocole et le client

Objectif

Définir le protocole et le client pour macOS Sequoia afin de poursuivre avec la configuration de la connexion et du kill switch système.

Instructions détaillées

1. Évaluez votre cas d’usage : si vous souhaitez une solution rapide et simple, optez pour WireGuard. Pour une compatibilité avec d'anciennes infrastructures, considérez OpenVPN. Pour une intégration native sans clients tiers, choisissez IKEv2.
2. Si vous choisissez WireGuard : installez l’application WireGuard pour macOS depuis une source fiable et préparez votre fichier .conf.
3. Pour OpenVPN : installez Tunnelblick ou Viscosity et préparez votre fichier .ovpn.
4. Avec IKEv2 : utilisez le client intégré macOS. Préparez les paramètres : adresse du serveur (IP), identifiant distant, identifiant local, authentification (login/mot de passe ou certificat) et activez l’option « Envoyer tout le trafic ».
5. Préparez l’adresse IP et le port du serveur : pour WireGuard c’est souvent UDP 51820 ; OpenVPN selon le port dans le fichier .ovpn ; IKEv2 utilise UDP 500 et 4500.

⚠️ Attention : Pour un kill switch système efficace, il est essentiel de connaître l’IP exacte du serveur, pas seulement le domaine. Les règles PF autoriseront uniquement cette IP et ce port. Si vous avez seulement un domaine, résolvez-le en IP avant et notez-la.

Astuce : Avec WireGuard, essayez d’avoir dans la config un AllowedIPs égal à 0.0.0.0/0, ::/0. Cela force tout le trafic à passer par le tunnel, simplifiant la logique et réduisant les risques de fuite.

Résultat attendu

Vous avez choisi un protocole, installé le client (ou décidé d’utiliser l’intégration native), et disposez d’un fichier de config fonctionnel avec IP et port du serveur connus.

Problèmes possibles et solutions

• Indécis sur le choix. Solution : WireGuard est le choix optimal pour macOS Sequoia : simple, rapide, léger.
• Vous n’avez qu’un domaine, pas d’IP. Solution : dans le Terminal, utilisez dig +short votre.domaine ou nslookup votre.domaine pour obtenir l’IP.
• UDP bloqué par le fournisseur. Solution : utilisez OpenVPN TCP 443 ou IKEv2, ou activez l’obfuscation si votre serveur la supporte.

✅ Contrôle : Vous avez le protocole choisi, le client installé (ou prêt à utiliser IKEv2), et les informations IP/port du serveur.

Étape 2 : Importer la configuration et connexion initiale

Objectif

Importer la configuration dans le client choisi et vérifier que le VPN se connecte et transmet le trafic.

Instructions pour WireGuard

1. Ouvrez l’application WireGuard sur Mac.
2. Cliquez sur « Importer un tunnel » ou « Add Tunnel » et sélectionnez le fichier .conf.
3. Vérifiez que le champ Address contient une adresse VPN (par exemple 10.14.0.2/32), PrivateKey est présent, et que dans Peer l’Endpoint affiche IP:port avec AllowedIPs = 0.0.0.0/0, ::/0.
4. Activez le tunnel via le bouton bascule. L’indicateur doit devenir vert et vous verrez le trafic « actuel / total ».

Instructions pour OpenVPN (Tunnelblick)

1. Lancez Tunnelblick.
2. Glissez le fichier .ovpn sur l’icône Tunnelblick dans la barre de menus ou ajoutez via le menu de l’application.
3. Choisissez « Seulement pour cet utilisateur » ou « Tous les utilisateurs » selon le besoin.
4. Connectez-vous en cliquant sur « Connect » à côté du profil. Saisissez login et mot de passe si demandé.

Instructions pour IKEv2 (client intégré)

1. Ouvrez « Préférences Système » → « Réseau » → « VPN » → « Ajouter une configuration VPN ».
2. Choisissez « IKEv2 ».
3. Indiquez l’adresse IP du serveur au champ « Serveur ».
4. Remplissez « Identifiant distant » (habituellement le domaine du serveur) et « Identifiant local » (votre identifiant, si nécessaire).
5. Choisissez le type d’authentification : « Nom d’utilisateur et mot de passe » ou « Certificat ». Remplissez les champs.
6. Activez l’option « Envoyer tout le trafic » ou équivalent.
7. Enregistrez et cliquez sur « Connecter ».

Astuce : Si vous avez accès à votre compte sur le service VPN, il est souvent plus simple d’utiliser les configs prêtes à l’emploi. Par exemple, sur vpn.how, vous pouvez directement télécharger des fichiers de configuration pour WireGuard, OpenVPN et IKEv2, à importer dans le client macOS. Ce fournisseur propose un serveur VPN personnel (non partagé), une IP dédiée, supporte WireGuard, OpenVPN, IKEv2, L2TP, SSTP, des infrastructures dans plusieurs villes mondiales, accepte les paiements russes (Tinkoff, Ozon), Sberbank, USDT/BTC, tarifs à partir de 490 ₽ par jour et 2490 ₽ par mois, avec réductions longues durées, démarrage de serveur en 5 minutes sans logs. C’est une option pratique pour avoir rapidement des configs fiables et une IP dédiée. Mentionnée ici succinctement pour ne pas alourdir.

Résultat attendu

Le VPN se connecte, vous avez accès à Internet via le tunnel, et les paramètres de base correspondent à la configuration.

Problèmes possibles et solutions

• Connexion impossible. Cause : port ou IP erroné. Solution : vérifiez l’Endpoint dans la config et demandez le port au fournisseur.
• Connecté mais pas d’Internet. Cause : routes ou DNS mal configurés. Solution : vérifiez AllowedIPs pour WireGuard ou l’option « Envoyer tout le trafic » pour IKEv2, ajoutez les DNS du tunnel.
• Demande de login à chaque fois. Solution : activez la sauvegarde des identifiants si la politique de sécurité le permet.

✅ Contrôle : Visitez un site affichant votre IP publique et vérifiez qu’elle correspond à celle du VPN. Déconnectez le VPN, l’IP doit changer. Cela confirme la bonne routage.

Étape 3 : Protection contre les fuites DNS et On-Demand

Objectif

Garantir que les requêtes DNS passent toujours via le VPN, et que celui-ci se connecte automatiquement sur les réseaux définis. Cela réduit les risques de fuite avant d’appliquer le kill switch système.

Instructions détaillées

1. Dans WireGuard, ouvrez le profil et vérifiez la présence d’une section DNS (exemple : DNS = 10.14.0.1 ou adresse DNS du tunnel). Si absente, ajoutez les serveurs recommandés dans votre config, pour que le client configure le DNS à la connexion.
2. Dans OpenVPN (Tunnelblick), assurez-vous que la config .ovpn contient une directive DNS poussée par le serveur (dhcp-option DNS 10.14.0.1 par exemple). Sinon, ajoutez manuellement les DNS dans macOS via Réseau → Adaptateur VPN → DNS après connexion.
3. Pour IKEv2, vérifiez que le serveur fournit les DNS via la config. Sinon, définissez-les manuellement dans la configuration VPN.
4. Activez le mode On-Demand (si disponible). WireGuard propose l’option « Activate on demand » et des règles basées sur SSID/réseaux. Dans Tunnelblick, utilisez « Se connecter au démarrage de l'ordinateur ». Sur IKEv2, activez « Connexion automatique » si proposé dans macOS.
5. Vérifiez qu’après redémarrage du Mac, le client relance le tunnel automatiquement à la première connexion réseau.

Astuce : Si votre Endpoint est un domaine, remplacez-le temporairement par l’IP durant la configuration du kill switch. Cela évite que le tunnel échoue à se monter à cause d’un DNS externe inaccessible. Une fois réglé, vous pourrez remettre le domaine et ajouter une règle PF autorisant le DNS pour cette résolution. Pour simplifier, ce guide part d’une IP fixe.

Résultat attendu

Le DNS passe par le tunnel et le VPN se connecte automatiquement. Ce n’est pas un kill switch complet, mais ça limite déjà les fuites.

Problèmes et solutions

• Le DNS fuit encore. Cause : priorités système DNS. Solution : désactivez les résolveurs tiers dans l’interface réseau active ou définissez matchDomains dans le client VPN si supporté.
• L’autoconnect ne fonctionne pas. Cause : conflit de politiques. Solution : vérifiez la config On-Demand et les autorisations de lancement automatique dans macOS.

✅ Contrôle : Exécutez scutil --dns pour voir si le résolveur actif est celui du tunnel VPN. Déconnectez le VPN et vérifiez que le résolveur change. Reconnectez et testez l’accès aux sites.

Étape 4 : Kill switch système via PF : configuration basique

Objectif

Créer une configuration PF minimale qui bloque tout le trafic sortant, sauf celui autorisé : vers le serveur VPN lors de l'établissement du tunnel, et via l’interface VPN une fois active.

Principe de fonctionnement

Nous activerons PF système et définirons un jeu de règles : bloquer tout par défaut, autoriser uniquement le trafic sur l’interface utun, et autoriser les paquets sortants vers l’IP et le port du serveur VPN sur l’interface physique pour établir le tunnel. Ainsi, si le tunnel tombe, votre trafic ne pourra pas sortir en direct – la politique n’autorise que la connexion au serveur VPN et le trafic chiffré via utun.

Préparation des données

1. Notez l’adresse IP du serveur VPN, par exemple 203.0.113.10.
2. Notez les ports : WireGuard 51820 UDP, OpenVPN 1194 UDP (ou votre port), IKEv2 500 et 4500 UDP.
3. Identifiez votre interface physique principale : lancez route -n get default et notez « interface: en0 » ou « en1 », par exemple en0.

Création d’un ancrage PF

1. Ouvrez le Terminal.
2. Créez un fichier d’ancrage : sudo nano /etc/pf.anchors/vpn-killswitch.
3. Collez les règles suivantes, ligne par ligne, en remplaçant par vos valeurs. Considérez chaque ligne comme un point distinct :

• set block-policy drop
• set skip on lo0
• block all
• pass quick on utun0 all keep state
• pass quick on utun1 all keep state (au cas où un autre utun est utilisé ; ajoutez utun2, utun3 si besoin)
• pass out quick on en0 proto udp to 203.0.113.10 port 51820 keep state (pour WireGuard)
• pass in quick on en0 proto udp from 203.0.113.10 port 51820 keep state (optionnel pour les paquets de réponse, mais stateful couvre déjà)
• pass out quick on en0 proto udp to 203.0.113.10 port 500 keep state (pour IKEv2)
• pass out quick on en0 proto udp to 203.0.113.10 port 4500 keep state (pour IKEv2)
• pass out quick on en0 proto udp to 203.0.113.10 port 1194 keep state (pour OpenVPN en UDP)
• pass out quick on en0 proto tcp to 203.0.113.10 port 443 keep state (pour OpenVPN TCP 443, si utilisé)

Enregistrez le fichier et quittez l’éditeur. Attention : intégrez uniquement les ports et protocoles correspondant à votre protocole ; supprimez les autres pour limiter la surface d’exposition.

Intégration dans pf.conf principal

1. Ouvrez le fichier principal : sudo nano /etc/pf.conf.
2. Ajoutez en fin de fichier la ligne d’ancrage : anchor "vpn-killswitch" puis, sous cette ligne, load anchor "vpn-killswitch" from "/etc/pf.anchors/vpn-killswitch".
3. Enregistrez et fermez l’éditeur.

Activation de PF et vérifications

1. Vérifiez la syntaxe : sudo pfctl -nf /etc/pf.conf. Aucune erreur ne doit apparaître.
2. Chargez la configuration : sudo pfctl -f /etc/pf.conf.
3. Activez PF si nécessaire : sudo pfctl -e.
4. Vérifiez les règles actives : sudo pfctl -sr. Les lignes configurées doivent apparaître.

Astuce : Si vous ne savez pas quelle interface utun est utilisée, ajoutez des règles « pass quick on utun0..utun3 ». C’est sécurisé et facilite la maintenance si le client crée plusieurs utun à chaque reconnexion.

⚠️ Attention : À ce stade, votre connexion internet peut disparaître si le VPN n’est pas connecté et sans règles autorisant l’IP/port serveur. C’est normal. Connectez le client VPN pour rétablir l’accès via le tunnel.

Résultat attendu

Avec PF activé, internet fonctionne uniquement lorsque le VPN est actif. A la déconnexion VPN, tout le trafic est bloqué sauf les tentatives vers l’IP et ports autorisés du serveur.

Problèmes et solutions

• Pas de connexion même avec VPN activé. Cause : mauvais utun ou règles pass manquantes. Solution : vérifiez via ifconfig quel utun est actif après connexion, ajoutez-le dans les règles et rechargez PF.
• VPN ne s’établit pas. Cause : trafic sortant vers serveur bloqué. Solution : ajoutez une règle pass out précise pour IP et port du serveur sur l’interface physique.
• Endpoint domaine non résolu. Cause : DNS bloqué avant connexion. Solution : remplacez temporairement par l’IP ou ajoutez une règle de résolution DNS spécifique, en gardant en tête le risque de fuite.

✅ Contrôle : Déconnectez VPN — internet doit disparaître. Reconnectez VPN — internet doit revenir. Lancez curl https://ifconfig.me et vérifiez que l’IP correspond au VPN. Sans VPN, la requête doit bloquer ou échouer.

Étape 5 : Automatisation du kill switch : script et LaunchAgent

Objectif

Assurer que les règles PF sont appliquées et maintenues actives aux redémarrages et reconnexions, avec possibilité de basculer rapidement en mode désactivé si besoin.

Instructions détaillées

1. Créez un script d’aide pour recharger PF et vérifier l’état des interfaces VPN. Tapez : sudo nano /usr/local/bin/vpn-ks-reload.sh.
2. Collez ligne par ligne, en adaptant si besoin :

• #!/bin/sh
• /sbin/pfctl -nf /etc/pf.conf || exit 1
• /sbin/pfctl -f /etc/pf.conf
• /sbin/pfctl -e
• exit 0

3. Sauvegardez et quittez.
4. Rendez-le exécutable : sudo chmod +x /usr/local/bin/vpn-ks-reload.sh.
5. Créez un LaunchAgent pour exécuter ce script au login utilisateur : nano ~/Library/LaunchAgents/com.local.vpnks.reload.plist.
6. Collez sans indentation, ligne par ligne, pour éviter les erreurs :

• <plist version="1.0"><dict><key>Label</key><string>com.local.vpnks.reload</string><key>ProgramArguments</key><array><string>/usr/local/bin/vpn-ks-reload.sh</string></array><key>RunAtLoad</key><true/></dict></plist>

7. Enregistrez le fichier. Chargez l’agent : launchctl load ~/Library/LaunchAgents/com.local.vpnks.reload.plist.
8. Testez : reconnectez-vous ou lancez manuellement /usr/local/bin/vpn-ks-reload.sh et vérifiez qu’il n’y a pas d’erreurs.

Astuce : Pour désactiver temporairement le kill switch, tapez sudo pfctl -d. Attention, cela désactive la protection système. Pour réactiver : sudo pfctl -e puis sudo pfctl -f /etc/pf.conf.

Résultat attendu

Au démarrage du Mac, les règles PF s’activent automatiquement. Les reconnexions VPN ne perturbent pas leur fonctionnement. Vous pouvez recharger PF à la volée avec une commande.

Problèmes et solutions

• LaunchAgent ne se lance pas. Cause : erreur dans le fichier plist. Solution : vérifiez la syntaxe, rechargez l’agent, consultez launchctl list et les logs Console.app.
• PF désactivé après mise à jour système. Solution : relancez sudo pfctl -e et rechargez les règles. Reconfigurez l’ancrage si nécessaire.

✅ Contrôle : Redémarrez le Mac, puis vérifiez avec sudo pfctl -sr que vos règles sont actives. Connectez/déconnectez le VPN, internet ne fonctionnera qu’avec VPN actif.

Étape 6 : Ajustement précis des règles selon protocole

Objectif

Garantir que le kill switch fonctionne de manière fiable avec WireGuard, OpenVPN et IKEv2, en tenant compte des particularités comme les ports et permissions additionnelles.

WireGuard

1. Laissez seulement l’autorisation UDP vers l’IP serveur et le port 51820 sur l’interface physique (par exemple en0). C’est strictement nécessaire pour la création du tunnel.
2. Vérifiez que AllowedIPs est bien 0.0.0.0/0, ::/0, clé pour le routage complet via utun.
3. Assurez-vous qu’un serveur DNS du tunnel est configuré pour éviter les fuites DNS.

OpenVPN

1. Avec UDP : autorisez proto udp to IP port 1194 (ou votre port) sur l’interface physique.
2. Avec TCP 443 : autorisez proto tcp to IP port 443.
3. Vérifiez que le serveur pousse bien la configuration DNS ou configurez-le manuellement sur le tunnel actif.

IKEv2

1. Autorisez proto udp to IP port 500 et proto udp to IP port 4500 sortant sur l’interface physique.
2. Activez « Envoyer tout le trafic » dans la config IKEv2 pour éviter que certains flux contournent le tunnel.
3. Vérifiez que le DNS est bien défini via le tunnel.

Astuce : Si vous changez souvent de réseau (domicile, bureau, hotspot mobile), contrôlez si l’interface physique change (en0, en1). Dans ce cas, ajoutez des règles pass pour chaque interface utilisée ou employez « group egress » pour autoriser la sortie vers l’IP serveur indépendamment de l’interface.

Résultat attendu

Vos règles PF sont précises et minimales : elles autorisent uniquement la création du tunnel vers votre serveur et le trafic VPN complet via ce tunnel, sans exception superflue.

Problèmes et solutions

• Connexion coupée au changement de réseau Wi-Fi. Cause : interface physique ou IP publique changée, port bloqué. Solution : ajoutez règles pour la nouvelle interface, ou utilisez OpenVPN TCP 443 en secours.
• Ping échouent vers ressources internes. Cause : routes et AllowedIPs incomplètes. Solution : incluez les sous-réseaux internes dans AllowedIPs ou ajustez le routage serveur.

✅ Contrôle : Effectuez un test : connectez le VPN, lancez plusieurs ping et traceroute vers une adresse externe. Déconnectez le VPN, assurez-vous que les nouvelles tentatives sont bloquées et que les connexions existantes cessent.

Étape 7 : Module avancé : bases de l’API Network Extension pour kill switch

Objectif

Comprendre comment, via Network Extension API, définir les paramètres qui influencent le comportement du trafic et implémenter un routage strict via tunnel. C’est optionnel et nécessite un compte développeur Apple.

Notes importantes

Travailler avec Network Extension sur macOS demande un abonnement Apple Developer et l’activation des entitlements. Certains fournisseurs spécifiques, comme le filtrage de contenu (NEFilter), nécessitent approbation Apple. Pour usage personnel et débogage, vous pouvez construire une app avec Packet Tunnel Provider si vous disposez des entitlements de base. Cette partie est informative et pour la pratique en environnement de test.

Classes clés et flags

• NEPacketTunnelProvider — point d’entrée du client VPN custom. Ici vous ouvrez le tunnel et gérez les paramètres réseau.
• NEPacketTunnelNetworkSettings — objet où vous définissez IPv4/IPv6, DNS, routes. Flags importants : includeAllNetworks = true et excludeLocalNetworks = true pour forcer le tunneling complet.
• NEVPNManager — gestionnaire de politique On-Demand et cycle de vie VPN (IKEv2 et Packet Tunnel).
• NEDNSSettings — permet de définir les DNS sur tunnel et matchDomains = [""] pour capturer toutes les requêtes DNS.

Étapes minimales dans Xcode

1. Dans Xcode, créez un projet App macOS. Ajoutez la cible Network Extension, type Packet Tunnel Provider.
2. Activez les entitlements : activez « Personal VPN ». Vérifiez que Signing & Capabilities inclut Network Extensions avec le fournisseur requis.
3. Dans le code, créez un NEPacketTunnelNetworkSettings. Configurez ipv4Settings avec l’adresse tunnel (exemple 10.14.0.2/32) et la route par défaut (0.0.0.0/0). Activez includeAllNetworks = true et excludeLocalNetworks = true.
4. Ajoutez des NEDNSSettings avec le DNS du tunnel et matchDomains = [""] pour forcer la capture DNS.
5. Configurez la politique On-Demand via NEVPNManager, avec des règles « Connect » sur tous les réseaux sauf éventuellement des SSID de confiance. Idéalement, pour kill switch ne rien exclure.
6. Compilez et lancez l’app localement, installez la configuration VPN système. Acceptez les demandes d’installation de profil, si présentées.

Astuce : pour usage privé plutôt que publication, gardez le projet et l’identifiant de bundle sous votre Apple ID. Cela simplifie l’installation et la gestion des profils sur votre Mac.

Résultat attendu

Vous disposez d’une configuration minimale fonctionnelle d’un client custom orienté redirection complète du trafic et DNS via le tunnel. Le kill switch système repose toujours sur PF configuré précédemment, combinant ainsi une double protection.

Problèmes et solutions

• Pas d’entitlement requis. Solution : vérifiez l’abonnement Apple Developer et ajoutez les capacités nécessaires dans Signing & Capabilities.
• Profil non installé. Solution : consultez les logs Console.app, la signature du binaire, et confirmez que l’app a les permissions nécessaires pour gérer VPN.
• Conflit avec client existant. Solution : n’exécutez pas simultanément le client système et le client custom utilisant le même tunnel.

✅ Contrôle : Vérifiez qu’un profil VPN apparaît dans les réglages réseau de macOS. A la connexion, tous les flux réseau et DNS passent par le tunnel. A l’arrêt, PF maintient le blocage du trafic.

Étape 8 : Tests complets : trafic, DNS, coupures

Objectif

Vérifier que le kill switch est fiable : aucun trafic sortant hors VPN, pas de fuite DNS, et en cas de coupure du tunnel, internet est bloqué instantanément.

Plan de test

1. Test de routage : avec VPN actif, lancez curl https://ifconfig.me et notez l’IP. Déconnectez VPN et assurez-vous que la requête échoue (grâce à PF).
2. Test DNS : avec VPN actif, exécutez scutil --dns et vérifiez que le résolveur est celui du tunnel. Faites un nslookup example.com et vérifiez le serveur DNS. Déconnectez VPN, vérifiez que le DNS est bloqué.
3. Test coupure : avec VPN actif, tuez manuellement le processus client ou changez de réseau Wi-Fi. Vérifiez que l’accès internet ne revient pas avant reconnexion VPN.
4. Test temps de récupération : mesurez le temps de reconnexion VPN après changement réseau, vérifiez que PF continue à bloquer durant ce temps.
5. Test applicatif : ouvrez navigateur, messagerie et lecteur média. Vérifiez qu’ils fonctionnent uniquement si VPN est actif.

Astuce : Pour une analyse détaillée, utilisez tcpdump sur l’interface physique : sudo tcpdump -i en0 not port 51820 (pour WireGuard). Si tout est bien configuré, aucun trafic utilisateur ne doit fuir avec PF actif.

Résultat attendu

Dans tous les cas, aucun trafic ni DNS ne fuit en l’absence de VPN. Au retour du tunnel, les applications retrouvent instantanément l’accès.

Problèmes et solutions

• Certains services système accèdent encore au réseau. Cause : exception manquante dans PF. Solution : vérifiez sudo pfctl -vvsr, détectez et éliminez les règles passiest inattendues, surtout ajoutées par d’autres applis.
• Retards à la reconnexion. Solution : activez On-Demand dans le client et simplifiez les règles PF au strict nécessaire.

✅ Contrôle : En résumé : sans VPN, tout est bloqué ; avec VPN, tout fonctionne ; DNS toujours via tunnel ; aucune fuite en cas de coupure.

Vérification finale

Checklist

• Client VPN installé et configuré (WireGuard, OpenVPN ou IKEv2).
• Configuration importée et IP/port serveur connus.
• DNS redirigé via tunnel, autoconnect activé (On-Demand).
• Ancrage PF créé et chargé dans /etc/pf.conf.
• PF actif avec règles persistantes après redémarrage.
• Internet accessible uniquement via VPN.
• Tests coupure et fuite DNS passés.

Comment tester

1. Répétez trois cycles : VPN activé — vérification IP/DNS ; VPN désactivé — pas de connexions ; VPN réactivé — accès restauré.
2. Testez divers réseaux Wi-Fi et Ethernet.
3. Analysez logs PF avec sudo pfctl -vvsr et sudo pfctl -vvss (états).

Critères de réussite

• Aucun trafic réseau sans VPN actif (sauf pour IP serveur et ports autorisés).
• Absence de réponse DNS hors VPN, résolution stable via tunnel.
• Récupération rapide des connexions applicatives après reconnexion VPN.

Erreurs fréquentes et solutions

• Problème : internet non fonctionnel même avec VPN. Cause : mauvais utun dans les règles PF. Solution : identifiez utun actif via ifconfig et ajoutez un pass quick on utunX dans l’ancrage.
• Problème : VPN ne se connecte pas. Cause : PF bloque la connexion serveur. Solution : ajoutez une règle pass out quick on enX proto udp/tcp to IP port NNNN adaptée.
• Problème : fuite DNS. Cause : DNS pas redirigé via tunnel. Solution : ajoutez DNS dans config WireGuard, pour OpenVPN utilisez push DNS ou configuration manuelle sur interface VPN.
• Problème : PF se désactive après mise à jour. Cause : redémarrage services système. Solution : relancez sudo pfctl -e et rechargez config, vérifiez LaunchAgent.
• Problème : certaines applis contournent le VPN. Cause : routing split tunnel. Solution : utilisez AllowedIPs 0.0.0.0/0 et ::/0, évitez le split-tunneling.
• Problème : impossibilité de compiler un exemple Network Extension. Cause : absence d’entitlements. Solution : souscrivez Apple Developer et activez les capacités dans Xcode.
• Problème : coupure lors des changements de Wi-Fi. Cause : port ou protocole bloqué par nouveau fournisseur. Solution : passez à OpenVPN TCP 443 ou profil de secours.

Fonctionnalités supplémentaires

Configurations PF avancées

• Utilisation de variables de table : créez une table pour l’IP serveur et définissez une seule règle pass, utile en cas de migration IP.
• Journalisation : activez le logging des blocages pour analyse via Console.app ou tcpdump -n -e -ttt -i pflog0.
• Granularité : si vous utilisez plusieurs protocoles, scindez leurs règles en ancrages séparés à charger dynamiquement.

Optimisation du client

• Sur WireGuard, ajustez le MTU (ex. 1420–1440) pour éviter la fragmentation.
• Sur OpenVPN, activez tls-crypt et configurez un chiffrement moderne.
• Pour IKEv2, utilisez un ensemble moderne de chiffrements et PFS si supporté par le serveur.

Autres possibilités

• MDM et profils : sur appareils d’entreprise, déployez des profils gérés avec politique On-Demand pour déployer largement.
• Profils de secours : préparez un profil VPN alternatif sur un autre port ou protocole pour réseaux filtrés sévèrement.
• Surveillance : configurez des alertes sur coupure de tunnel via événements système ou script qui vérifie l’état des interfaces et écrit dans un log local.

Astuce : Si vous êtes souvent en déplacement et rencontrez divers réseaux invités, gardez à portée plusieurs profils avec ports et protocoles variés pour garantir l’accès VPN malgré les restrictions.

FAQ

1. Peut-on faire un kill switch sans PF ? Oui, certains clients intègrent un kill switch, mais PF offre une garantie système indépendante des clients.
2. Faut-il un domaine au lieu d’une IP ? Pas forcément. Pour la robustesse, l’IP est plus simple à gérer dans PF. Le domaine est utile pour la redondance mais nécessite une gestion fine des exceptions DNS.
3. Comment savoir quel utun utiliser ? Connectez VPN puis lancez ifconfig. L’utun actif avec traffic comptabilisé est celui utilisé.
4. IPv6 est-il utilisable ? Oui. Ajoutez ::/0 aux routes et vérifiez que le serveur supporte IPv6. Les règles PF IPv6 sont similaires mais ajustez protocoles et adresses.
5. Et si je ne suis pas Apple Developer ? Pas de souci. Le kill switch principal avec PF fonctionne sans Network Extension. La partie avancée est optionnelle.
6. PF doit-il être toujours activé ? Oui, pour un kill switch actif en permanence. Désactivez temporairement uniquement en connaissance de cause.
7. Comment mettre à jour la config en toute sécurité ? Déconnectez VPN, mettez à jour config, vérifiez syntaxe PF, reconnectez VPN et réappliquez PF. Gardez toujours IP et ports serveur disponibles.
8. Les réseaux locaux (imprimantes, NAS) fonctionnent-ils ? Par défaut, non, si tout passe par le tunnel. Ajoutez des exceptions dans les routes VPN pour certains sous-réseaux si vous le souhaitez, en comprenant les risques.
9. Comment détecter une fuite WebRTC ? Désactivez WebRTC dans le navigateur ou utilisez une extension. Le plus sûr reste le kill switch système avec routes complètes.
10. Peut-on automatiser le changement de profils ? Oui, par script ou outils client (WireGuard a CLI). Laissez PF intact et gérez les IP serveur dans les tables autorisées.

Conclusion

Vous avez suivi un parcours complet : choix du protocole et client, import de configuration, réglage DNS et On-Demand, activation du kill switch système via PF, automatisation et tests variés. Résultat : un système fiable où votre trafic sort uniquement par VPN et est totalement bloqué en cas de coupure.

Vous pouvez désormais affiner les configurations multiplateformes, gérer des règles PF avec tables, approfondir l’API Network Extension pour clients personnalisés et, en milieu professionnel, utiliser des profils gérés. Une bonne configuration assure haute disponibilité, prévisibilité, sécurité, et diagnostics transparents via les logs PF.

Astuce : Revoyez régulièrement vos règles, surtout après les mises à jour macOS, et vérifiez qu’elles fonctionnent toujours comme prévu. Le script de rechargement PF et la checklist du contrôle final vous faciliteront la tâche.

⚠️ Attention : Ne surchargez pas PF avec des exceptions inutiles « au cas où ». Plus la liste des autorisations est compacte et précise, plus le kill switch est fiable et stable face aux changements de réseau.