Conservez le trafic de retour établi pour les connexions SOCKS sortantes de SSH
Une session SSH peut survivre tandis que le pare-feu du serveur rejette les réponses des sites web arrivant sur des ports locaux éphémères.
Si la navigation via SOCKS casse après des changements sur le pare-feu du serveur SSH, ne jugez pas tout le trajet d'après le shell SSH encore vivant. Le serveur ouvre des connexions TCP de destination distinctes pour le transfert dynamique.
Leurs réponses arrivent sur des ports éphémères choisis par le serveur. Une politique qui n'autorise le nouveau trafic entrant que vers le service SSH peut rejeter ces paquets si le trafic établi n'est pas accepté.
Dans un ensemble de règles IPv4 iptables existant, le fragment d'état de connexion est :
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTPlacez-le avant une règle finale drop/reject correspondante. Il admet le trafic de retour suivi, et non chaque nouvelle connexion vers un port haut.
Utilisez le tuple rejeté et l'état pour vérifier cette cause. OUTPUT doit autoriser la connexion ultérieure, et les chemins IPv6 ont besoin de leurs règles applicables. La négociation SOCKS, le transport SSH et le trafic de destination sont des étapes distinctes à inspecter.