共计 2492 个字符，预计需要花费 7 分钟才能阅读完成。
Après avoir construit un système DNS magique basé sur OpenClash + mosDNS + AdGuardHome, l'expérience du réseau a été considérablement améliorée, mais nous avons également rencontré le problème de l'instabilité du mappage des ports du bureau à distance. Dans cet article, nous allons passer en revue les détails de ce qui suit OpenClash 的“来源流量访问控制”功能成功解决该问题的过程，并提供安全映射建议，帮助你稳定又安心地远程访问内网设备。这是有公网的情况下我们使用DDNS远程访问我们局域网设备，如果没有公网IP我们也可以使用Cloudlfare新功能Zero Trust的Tunnel实现内网穿透，既安全又快速的免费远程访问我在《告别无公网 IP 焦虑：用 Cloudflare Tunnel / Zero Trust 打造真正可分享的飞牛fnOS NAS 免费远程访问方案》有详细的讲解与设置说明，支持多种协议模式，HTTPS的Web访问，SSH远程登录、包括我们的远程桌面、FTP等等，并且还支持邮箱验证，也更加的安全。感兴趣的有没有公网IP的可以一试。
Dans le dernier tutoriel, nous avons parcouru la rubrique OpenClash + mosDNS + AdGuardHome Elle a créé un système de magie DNS à guichet unique, et les trois travaillent ensemble pour maximiser l'optimisation de l'expérience du réseau :
- OpenClashResponsable de la gestion de l'informationaccès scientifique à l'internetLe système de gestion de l'information, le triage des politiques et les mandataires transparents sont autant d'outils qui permettent d'améliorer la qualité de l'information ;
- mosDNSResponsable de la transmission du cryptage DNS, de l'anti-pollution et de la gestion des flux multiples ;
- AdGuardHomeLa première ligne de défense consiste à recevoir les requêtes DNS des clients, à donner la priorité au blocage des domaines annoncés, puis à les transmettre à mosDNS pour traitement ultérieur.
Pour visualiser cette page, veuillez l'ouvrir dans un environnement Internet avec accès à YouTube.
Une description graphique complète est fournie ci-dessous et peut être lue plus loin.
Le lien complet pour une requête DNS est illustré ci-dessous :
Client → AdGuardHome → mosDNS → OpenClash (transfert ou connexion directe) → Extranet
Cette architecture bloque les publicités et évite la pollution DNS, tout en travaillant avec Scientific Internet Access pour obtenir une expérience d'accès au web efficace, propre et stable.
🧱 Problèmes de connexion instable au bureau à distance
Cependant, dans la pratique, j'ai rencontré un petit problème - leConnexion extrêmement instable pour l'accès au bureau à distance (RDP) via DDNSLa connexion est souvent “perdue” ou “intermittente”.
Ce qui me perturbe, c'est que cela s'est déjà produit lorsque j'ai utilisé l'option PassWall+MosDNS+AdGuardHome Je n'ai jamais eu d'erreur de connexion lorsque je l'utilise en combinaison comme outil internet scientifique. Pour les utilisateurs qui, comme moi, utilisent le bureau à distance, il s'agit manifestement d'un problème incontournable.
Après de nombreuses recherches, j'ai trouvé un réglage possiblement pertinent dans les paramètres du plugin d'OpenClash :
🔧 Contrôle d'accès au trafic source
Dans le menu Paramètres d'OpenClash, il y a un menu nommé “Contrôle d'accès au trafic source” La description officielle du module est la suivante :
- Le trafic provenant des ports spécifiés localement ne passera pas par le noyau. Vous pouvez essayer de l'activer lorsque le transfert échoue sous la passerelle de contournement (routage de contournement) ;
- En mode Fake-IP, le filtrage des demandes de type IP pur est uniquement pris en charge.
Cette fonction nous permet de faire des exceptions pour le trafic provenant de ports spécifiés.Contourner le Clash Corepermettant à ce trafic de passer par le mécanisme natif de routage et de transfert du système.
J'ai configuré le serveur en fonction du numéro de port réel (3389), la connexion au bureau à distance est immédiatement devenue fluide et stable, il n'y a plus de problèmes de perte ou d'échec de connexion, donc si des partenaires ont également rencontré une connexion instable, vous pouvez essayer d'ouvrir un tel serveur, j'espère que cela pourra résoudre votre problème.
🛡 Conseil de sécurité : n'exposez pas le port 3389 directement !
Bien que nous puissions maintenant stabiliser l'accès à distance, pour des raisons de sécuritéIl est fortement déconseillé de faire correspondre directement le port 3389 de l'intranet au réseau public.Parce que 3389 est le port par défaut pour les bureaux à distance. Le port 3389 étant le port par défaut pour le bureau à distance, il est très sensible au balayage, aux tentatives de force brute et aux risques de sécurité élevés.
Les pratiques recommandées sont les suivantes :
Vous pouvez également utiliser ZeroTier, FRP, WireGuard, etc. pour pénétrer dans l'intranet au lieu d'utiliser le mappage de ports.
Définir le port public sur unport de haut niveau(par exemple, 54289), qui est ensuite transmis à l'intranet 3389 ;
Renforcer les mots de passe de connexion à distance et éviter d'utiliser des mots de passe faibles ;
Activer la politique de verrouillage de l'échec de la connexion au système pour empêcher le blasting ;
Utilisez les règles du pare-feu ou la liste blanche GeoIP pour restreindre les sources ;
Ici, j'utilise le mappage extranet avec un mappage de port différent pour le port de classe LAN 3389 utilisé, l'exemple suivant est un mappage de port de routage.
✅ Résumé
Si vous utilisez OpenClash en tant que proxy transparent et que vous établissez des connexions de bureau à distance via DDNS, et que vous rencontrez une instabilité de la connexion, essayez d'activer “Contrôle de l'accès au trafic à la source”Ce dernier empêche OpenClash d'interférer avec le trafic sur le port spécifié et garantit que le bureau à distance est stable et disponible.
Ne négligez pas non plus la sécurité de l'accès à distance, et n'oubliez pas d'effectuer un bon travail de dissimulation de port, d'anti-scanning, d'anti-bursting et d'autres mesures de sécurité, afin d'avoir l'esprit tranquille.
Chinese 
English 
Spanish 
French 
German 
Japanese 
Portuguese 
Italian 
Dutch