INFRASTRUCTURE PRIVÉE / AUCUNE PIÈCE D'IDENTITÉ REQUISELire la doctrine de confidentialité
Les notes du champ KoalaVPS

Un tunnel privé avec un objectif clair.

WireGuard peut connecter vos appareils à un serveur ou à un réseau privé. Ses avantages dépendent d'un routage correct, de DNS et de la sécurité des points de terminaison.

Définir la route

Déterminez si le tunnel transporte uniquement le trafic des services privés ou tout le trafic internet. Configurez intentionnellement les routes autorisées et tenez compte à la fois de IPv4 et de IPv6. Une configuration en split-tunnel et en full-tunnel présentent des considérations différentes en matière de fuites et d'accessibilité.

Conservez une clé par appareil

Générez les clés privées sur l'appareil lorsque c'est possible et ne les publiez jamais. Utilisez des identités de pairs distinctes afin qu'un appareil perdu puisse être révoqué sans remplacer chaque client. Stockez la configuration du serveur avec des permissions protégées.

Configurer le transfert et DNS

Configurez délibérément le transfert de ports et les règles de pare-feu. Vérifiez la résolution de noms, le MTU et le chemin de retour. Testez l'adresse publique effective et le comportement de DNS depuis le client, au lieu de supposer qu'une poignée de main réussie signifie que tout le trafic emprunte la route prévue.

Comprendre le changement de confiance

Un VPN auto-hébergé peut protéger le trafic sur le réseau local, mais le VPS et l'amont voient encore les métadonnées et tout trafic non chiffré. Il ne rend pas une session de navigateur anonyme et ne supplante pas les politiques des services auxquels vous accédez.

Utilisez un écouteur explicite et inspectez la poignée de main

UDP 51820 est un choix de configuration WireGuard courant, et non une politique d'hôte obligatoire ou garantie. Ouvrez uniquement le port UDP choisi et maintenez l'administration restreinte séparément. La commande wg show peut rapporter les informations de handshake et de transfert des pairs sans que vous ayez à publier de clés privées.

  • Vérifier un handshake récent
  • Testez le service privé prévu
  • Testez les routes Internet et DNS uniquement si un tunnel complet est prévu
wg show

N’utilisez les keepalives que lorsque le réseau en a besoin

Un pair derrière NAT peut nécessiter un trafic keepalive périodique pour préserver une correspondance pour les paquets entrants. Le réglage approprié dépend du réseau. Gardez la configuration intentionnelle ; ne copiez pas une recette de tunnel complet si l'objectif est seulement d'accéder à une application privée.

Choisir le split tunnelling ou une conception en tunnel complet

Commencez par l'objectif réel. Un tunnel fractionné peut ne transporter qu'un sous-réseau privé ou un service d'administration ; un tunnel complet nécessite aussi le transfert Internet, des règles de sortie et un plan DNS. Choisissez des adresses de tunnel non chevauchantes et décidez comment IPv6 est géré. UDP51820 est un port courant, pas un port obligatoire. Confirmez la politique de l'hôte sélectionné et maintenez l'accès console/administrateur disponible pendant la modification des routes ou des règles de pare-feu.

  • Attribuez à chaque appareil une paire de clés unique et une identité de pair étroite.
  • Conservez les clés privées sur les appareils prévus à cet effet et hors des fichiers publics ou du partage par QR code.
  • Traitez les points de terminaison publics et l'itinérance des clients comme partie intégrante de la conception du réseau.

Établir un petit tunnel avant d'ajouter le routage internet

Suivez l'installation du système d'exploitation pris en charge et générez les clés avec des permissions de fichier restrictives. Configurez l'interface serveur, un pair et l'écouteur UDP choisi. Un pair côté serveur doit normalement avoir sa propre adresse de tunnel dans AllowedIPs plutôt qu'un fourre-tout chevauchant attribué à plusieurs clients. Commencez par l'accès à l'adresse du tunnel, puis ajoutez le transfert et les routes de destination approuvés. Une poignée de main réussie prouve le contact avec le pair, pas que DNS ou la sortie Internet soit correcte.

# Inspection examples; these do not reveal a private key:
wg show
ip address show dev wg0
ip route get 10.44.0.1

Tester le chemin attendu et un chemin interdit

Depuis le client, vérifiez une poignée de main récente et un service privé autorisé. Essayez une destination qui devrait être refusée. En cas de tunnel complet, vérifiez la route publique effective, le résolveur DNS et le comportement IPv6 depuis ce client ; le trafic en tunnel divisé doit conserver le chemin local prévu. Répétez après un changement de réseau du client. N'utilisez un keepalive NAT que lorsque le réseau du pair en a besoin, et gardez un intervalle cohérent avec la conception documentée.

  • Aucune poignée de main : inspectez le point de terminaison DNS, l'accessibilité UDP, les clés et le mappage des pairs.
  • Poignée de main mais aucun service : inspectez AllowedIPs, le pare-feu, le transfert et la route de retour.
  • Certains sites se bloquent : examinez le MTU de chemin avant d'appliquer une valeur permanente arbitraire.

Rendre la révocation et le comportement au redémarrage reproductibles

Supprimez la clé de pair d'un appareil perdu et confirmez qu'il ne peut plus établir l'accès prévu. Conservez des sauvegardes chiffrées de la configuration et un inventaire indiquant quelle clé publique appartient à quel appareil. Vérifiez si l'interface et les règles de routage requises reviennent après un redémarrage normal. Un VPN déplace la confiance vers le VPS et son amont ; il ne supprime ni les identifiants applicatifs, ni les cookies de compte, ni la nécessité de HTTPS vers la destination finale.

CONFIGUREZ VOTRE INFRASTRUCTURE

Prenez le contrôle.
Déployez selon vos conditions.

Aucun justificatif d'identité. Accès administrateur complet. Facturation native en crypto.