
La censure devient de plus en plus astucieuse chaque année. Ce qui fonctionnait l'été dernier est bridé ou piraté cet hiver. L'objectif de ce guide et du script qui l'accompagne est simple : arrêtez de jouer au chat et à la souris. Construisez un transport qui ressemble à la navigation web de l'extérieur, mais qui utilise un tunnel privé rapide en dessous. Juste du TLS, rien à voir ici.
L'idée en un souffle
- Client ↔ Edge (saut d'entrée) : VLESS + RÉALITÉ sur TCPDu point de vue du câble, il s'agit simplement de TLS 1.3 vers un site Web normal (le SNI que vous avez choisi).
- Bord ↔ Sortie (saut de sortie) : WireGuard sur UDP pour la vitesse (ouais).
- Sortie ↔ Internet : NAT vers le Web ouvert.
LA RÉALITÉ fait que votre ClientHello ressemble à un navigateur légitime accédant à un vrai site (par exemple, google.com). La boîte de bord termine cela tandis que lier tous les messages sortants à WireGuard, qui transporte vos paquets jusqu'au boîtier de sortie. Ce dernier communique ensuite avec Internet. Pas de signatures criardes, pas de ports tape-à-l'œil. Les gouvernements ne peuvent pas bloquer cela sans causer de dommages collatéraux, autrement dit, endommager des sites web normaux.
[Device] --(TLS1.3/REALITY over TCP)--> [Edge/Entry]
(WireGuard/UDP)
----------------------------->
[Egress/Exit] --(NAT)--> Internet
Ce n'est pas de la magie, et ça ne marchera pas. certainement Réussir une enquête ciblée, c'est à ça que sert I2P (en quelque sorte). Mais pour la censure quotidienne et les boîtiers DPI bruyants, c'est ennuyeux, dans tous les sens du terme.
À qui s'adresse-t-il ?
- Vous avez besoin d'un fiable connexion via un filtrage puissant (par exemple, Great Firewall) sans passer les week-ends à échanger des configurations.
- Tu veux un script qui gère IPv4/IPv6, des valeurs par défaut saines, une configuration idempotente et un environnement propre purge changer quand les choses se bloquent.
- Vous préférez TCP à la périphérie (plus difficile à bloquer sans interrompre le Web normal) et Vitesse UDP là où c'est sûr : entre vos propres serveurs.
Ce n'est pas votre cas d'utilisation si vous souhaitez un VPN grand public à clic unique ou si vous ne contrôlez pas au moins le premier VPS. Vous pouvez utiliser un VPN commercial comme deuxième saut Mais choisissez-en un qui vous offre des configurations WireGuard simples. Si vous insistez pour NordVPN, ça fonctionne, mais c'est plus compliqué.
Ce que vous obtenez (fonctionnalités)
- Double-saut par conception : Camouflage TCP sur le bord, performances WireGuard en dessous.
- RÉALITÉ: Poignée de main TLS 1.3 de type navigateur vers un hôte réel (SNI doit être un nom DNS réel avec un SAN valide).
- Modes IPv4/IPv6 : v4 uniquement, double pile ou v6 préféré.
- Option de renforcement de Systemd : Courir
sing-boxen tant que dédiésingboxutilisateur avec des capacités restreintes. - Sensibilisation aux tables nftables/iptables : Utilise iptables par défaut ; enregistre le backend sur lequel vous vous trouvez afin que vous ne soyez pas surpris sur Ubuntu 24.04+.
- Sonde de santé : Un petit vérificateur pour confirmer la cohérence de SNI, TLS 1.3 et de l'échange de clés.
- Mode de purge :
--purgedétruit le service, les configurations, l'utilisateur et les journaux ;--flush-iptablesrestaure éventuellement vos règles de pré-installation.
Modèle de menace (court et honnête)
- Filtrage de masse des battements (DPI basé sur des empreintes VPN connues, blocage SNI/JA3 faible, blocages de ports naïfs).
- Ne battra pas la compromission ciblée du point de terminaison ou une analyse puissante et sur mesure par rapport à vos serveurs exacts.
- Questions de sécurité opérationnelle : Ne réutilisez pas les boîtes pour des services sans rapport ; maintenez le système d'exploitation et le noyau à jour ; épinglez les versions lorsque vous le pouvez.
Exigences
- Deux serveurs Linux (Ubuntu 22.04/24.04 fonctionnent très bien).
- Bord (entrée): IP publique accessible depuis le client (il doit s'agir d'un VPS dans votre pays d'origine). Les gouvernements n'appliquent généralement pas de restrictions complètes aux entreprises de cloud.
- Sortie: IP publique avec UDP autorisé ; c'est votre point de sortie Internet.
Le saut de sortie peut également être une configuration WireGuard fournie par votre fournisseur VPN, bien que seuls quelques-uns fournissent des configurations wg.
- Possibilité d'ouvrir des ports sur le pare-feu/les groupes de sécurité de votre fournisseur :
- Bord : un TCP port pour la RÉALITÉ (par exemple, 443 ou un port élevé discret).
- Sortie : a UDP port pour WireGuard (par exemple, 51820).
- UN vrai SNI (nom d'hôte) présent dans le certificat SAN du site cible (par exemple,
google.com).
C'est le site Web que vous souhaitez voir apparaître lorsque vous naviguez.
Démarrage rapide (deux étapes, invites minimales)
1) Sortie (2e saut)
Il s'agit de votre serveur WireGuard et de votre NAT vers Internet.
# Example: listen on UDP 51820
wget https://raw.githubusercontent.com/abdessalllam/SuperSpeedVPN/refs/heads/main/installer.sh
chmod +x installer.sh
# ReadME for Links: https://github.com/abdessalllam/SuperSpeedVPN
sudo ./installer.sh --role 2nd --wg-port 51820 --silent Ce qu'il fait :
- Installe WG, configure le serveur, active la redirection IPv4/IPv6, les règles de pare-feu de base et NAT.
- Imprime un petit paquet que vous pouvez copier sur le bord.
Une fois que vous avez terminé, déplacez-vous wg-link-bundle.tar.gz fichier vers votre 1er hop ~ (/root/).
2) Bord (1er saut)
C'est ici que votre client se connecte à REALITY via TCP. Le périphérique utilise WG comme sortant.
# Example: TCP 443 for REALITY, SNI is a real hostname (must be DNS, not an IP)
wget https://raw.githubusercontent.com/abdessalllam/SuperSpeedVPN/refs/heads/main/installer.sh
chmod +x installer.sh
# ReadME for Links: https://github.com/abdessalllam/SuperSpeedVPN
# Use an SNI that's not blocked in your country
sudo ./installer.sh --role 1st --reality-port 443 --sni google.com
# The script will only allow domains that support TLS 1.3Remarques :
- Si vous ne fournissez pas de cible de poignée de main, cela par défaut
SNI:443. - Le bord lie sa sortie à
wg0, donc tout sort par le saut de sortie.
3) Client
Utilisez n'importe quel client moderne prenant en charge VLESS + REALITY (par exemple, Sing-Box). Le script génère un extrait prêt à être importé.
Comment utiliser un fournisseur VPN comme 2e saut
- Ignorez l'installation du 2e saut car vous n'avez pas accès au deuxième serveur.
- Obtenez les clés de configuration WireGuard et utilisez votre premier serveur de saut si le fournisseur VPN demande l'adresse IP de l'appareil.
- Créez un fichier Tar Gz nommé
wg-link-bundleavec 3 fichiersh2_publickeyavec une clé publique wg simple,h1_privatekeyavec une clé privée wg simple,varsavec les détails suivants :
Get the following from your WG Config and create 3 files.
# h2_publickey file:
EXAMPLEPUBLICKEYHGHD78HD
#h1_privatekey file:
EXAMPLEPRIVATEKEYHGHD78HD
# vars file:
WG_PORT=53133
WG_IF=wg0
WG_H1_V4=10.43.0.1/32
WG_H1_V6=fd00:43::1/128
WG_H2_V4=10.43.0.2/32 # From AllowedIPS list in your WG Config
WG_H2_V6=fd00:43::2/128 # From AllowedIPS list in your WG Config
H1_V4_POOL=10.43.0.0/24
H1_V6_POOL=fd00:43::/64
IPV6_MODE=dual # or ipv4only, dual means ipv4/ipv6
H2_ENDPOINT=IP:53133 # WG Config endpointEnsuite, compressez-les et téléchargez-les sur /root/ et exécutez le script 1st-hop.
Purger et réinstaller (votre « gros bouton rouge »)
Si quelque chose de bizarre s'est produit, ou vous voulez simplement repartir à zéro :
# Remove sing-box service, configs, binary, logs, and singbox user
sudo bash installer.sh --purgeExécutez ensuite à nouveau le démarrage rapide. La routine de purge est idempotente ; utilisez-la chaque fois que vous avez besoin de réinitialiser.
Modes IPv6 (et quand s'en soucier)
- Double pile (par défaut) : Meilleure accessibilité et meilleures performances lorsque les versions v4 et v6 sont disponibles.
- v4 uniquement : Pratique lorsque les chemins v6 sont instables ou déclenchent des heuristiques « VPN » spécifiques au site.
- v6-préféré : Idéal dans les régions où les itinéraires v6 sont moins encombrés.
Le script protège contre une interface WAN v6 vide lors de la configuration accept_ra=2, pour ne pas vous retrouver avec des sysctls cassés.
Vérification de la réalité du backend du pare-feu
Ubuntu 24.04 s'appuie sur tables nft même lorsque vous installez iptables-persistentLe script enregistre le backend actif avant d'appliquer les règles de verrouillage. Si vous êtes un puriste, remplacez le scripteur de règles par un script natif. nftou conservez iptables pour la portabilité ; soyez simplement conscient de la couche de traduction.
Contrôles de santé (faire confiance mais vérifier)
Après l'approvisionnement, exécutez la sonde pour confirmer que la couche de camouflage se comporte bien :
./installer.sh --probe --sni google.com
Vous voulez voir :
- TLS 1.3 négocié
- X25519 (ou un autre groupe ECDH sensé)
- SNI répertorié dans le certificat SAN
Si la sonde échoue, vérifiez que votre SNI est un Nom d'hôte DNS et accessible, et que votre port RÉALITÉ est ouvert.
Des conseils de performance qui comptent
- Utiliser TCP BBR sur les deux serveurs :
echo "net.core.default_qdisc=fq" | sudo tee /etc/sysctl.d/99-bbr.conf echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.d/99-bbr.conf sudo sysctl --system - Choisissez un port UDP WireGuard silencieux (pas 51820 si votre fournisseur le détecte).
- MTU de taille adaptée: Les valeurs par défaut de WG sont bonnes, mais si vous constatez une fragmentation, expérimentez (par exemple, 1280-1380).
- Versions de broches et éviter
curl | shPour la production. Téléchargez, vérifiez les sommes de contrôle et les signatures, puis installez.
Dépannage (chemin rapide)
- Le client ne peut pas se connecter à Edge : Est-ce la RÉALITÉ TCP Port ouvert sur le pare-feu de votre fournisseur ? SNI est-il un vrai nom d'hôte, et non une adresse IP ?
- Edge ne peut pas atteindre la sortie : Vérifiez que WG UDP est accessible de la périphérie à la sortie. Si vous êtes derrière un port montant strict, essayez un autre port ou activez le holepunching UDP sur UDP si votre fournisseur le prend en charge.
- C'est « connecté » mais pas d'internet : Vérifiez la NAT/le transfert en sortie. Le transfert IP doit être activé ; les règles MASQUERADE doivent exister.
- Comportement géographique/streaming étrange : Si certains sites sont sensibles à l'IPv6, basculez temporairement le bord vers v4 uniquement et retester.
- Le port WG est affiché fermé de l'extérieur : Certains clouds bloquent par défaut. Vérifiez les groupes de sécurité, les listes de contrôle d'accès (NACL), le pare-feu de l'hôte, puis
ss -ulpn. Vous ne le ferez peut-être pas recevoir trafic dû aux politiques UDP côté fournisseur.
Pourquoi cela résiste à la pression
- Camouflage plutôt que confrontation : Il est plus facile de passer le filtre si vous ressemblez à un TLS normal. La réalité le confirme.
- Contrôle des dégâts : Vous ne perdez pas tout si l'IP de sortie est signalée ; échangez la sortie, gardez le bord/SNI stable.
- Interrupteurs opérationnels : Les modes IPv6/IPv4, la purge et les réexécutions idempotentes rendent la maintenance ennuyeuse, exactement ce que vous voulez.
Ce guide se concentre sur confidentialité et fiabilité « ne pas enfreindre les lois ».
Clôture
Les configurations fragiles ont la vie dure. Celle-ci est faite pour l'ennui : TLS en haut, UDP en bas, paramètres par défaut impeccables et un bouton d'urgence en cas de besoin. Configurez-la, vérifiez-la, documentez les ports/SNI choisis et poursuivez votre vie. Les censeurs continueront d'innover ; nous aussi, mais nous le ferons avec une approche simple et facile à maintenir.

