Faire tourner des IP de proxy sans VPN : ce que la sortie voit
Faites tourner les sorties de proxy sans VPN : ce qu'un proxy HTTP peut lire, comment les sessions collantes évitent un état cassé et quelle sortie vous pouvez défendre dans une politique.
La rotation de proxy et un VPN changent votre adresse publique à des couches différentes, et cette différence décide de ce qui fuit. Un VPN déplace chaque paquet dans un tunnel, donc l'adresse source que voit la cible est le point de sortie du tunnel. Un proxy se situe au-dessus de la couche réseau : seules les requêtes que vous envoyez à travers lui apparaissent depuis la sortie, tandis que tout le reste sur la machine conserve l'adresse réelle. Bien régler cette séparation transforme la rotation d'une case à cocher en décision de conception.
D'où vient réellement l'adresse publique
L'adresse que voit une cible est celle d'où votre trafic est parti en dernier, et sur une connexion domestique c'est l'adresse du fournisseur sur votre routeur, pas quelque chose que la machine possède. Redémarrer le routeur peut rendre le même bail, et changer son adresse MAC en produit parfois un nouveau, mais ni l'un ni l'autre ne vous donne un sélecteur de pays. Un VPN remplace l'adresse source au niveau IP, donc chaque paquet de la machine, y compris le DNS et les mises à jour en arrière-plan, part du point de sortie du tunnel. Un proxy travaille une couche plus haut : il accepte une requête, ouvre sa propre connexion vers la cible, et seule cette requête apparaît depuis la sortie. Tout le reste sur la machine utilise encore l'adresse réelle.
Cette séparation explique la plupart des surprises. Une extension de navigateur pointée vers un proxy change ce que le navigateur envoie et rien d'autre, donc une seconde application sur le même hôte fuit encore l'adresse d'origine. Un VPN à l'échelle du système a le mode de défaillance inverse : il couvre le trafic que vous vouliez garder local et ne ferme que si le client est configuré pour. Choisir entre les deux revient vraiment à choisir quel trafic doit bouger.
La rotation s'applique alors à la couche que vous avez choisie. Avec un proxy, la rotation signifie que la requête suivante utilise une autre sortie. Avec un VPN, elle signifie démonter et reconstruire le tunnel, ce qui est plus lent et se voit comme une reconnexion visible.
Ce qu'un proxy HTTP peut lire, et ce qu'il ne peut pas
En HTTP simple, le proxy voit un URI absolu dans la ligne de requête, chaque en-tête et le corps. Il peut tout journaliser et réécrire n'importe quelle partie, et c'est pourquoi un proxy gratuit qui injecte un script dans les réponses fait exactement ce que le protocole permet. L'authentification utilise Proxy-Authorization, et un identifiant absent ou erroné produit 407 Proxy Authentication Required plutôt qu'une erreur de connexion.
En HTTPS, le client envoie CONNECT host:port et le proxy ouvre un tunnel brut, après quoi il voit des octets chiffrés. Il apprend toujours le nom d'hôte depuis la ligne CONNECT et généralement depuis le champ SNI de la poignée de main TLS, donc la journalisation au niveau du nom d'hôte survit même quand la charge utile ne survit pas. Lire la charge utile exige de terminer TLS avec un certificat auquel le client fait confiance, ce qui est un autre produit avec un autre risque. La spécification de sémantique HTTP définit CONNECT comme une requête de tunnel, ce qui est le bon modèle mental pour ce qu'une sortie peut et ne peut pas voir.
curl -v -x http://proxy.example.net:8080 https://example.com 2>&1 | grep -E 'CONNECT|Proxy-'La sortie détaillée montre la ligne CONNECT avant tout trafic TLS, et c'est le moment où le proxy apprend votre destination. Un proxy qui répond par 407 n'a jamais ouvert le tunnel, donc réessayer avec d'autres réglages TLS n'aidera pas.
La granularité de la rotation décide de ce qui casse
Tourner à chaque requête est le réglage qui semble le plus sûr et casse le plus. Les cookies, les jetons CSRF et les sessions côté serveur sont liés à une identité, et une identité qui change entre la connexion et l'appel suivant ressemble pour la cible à un détournement de session. Beaucoup de fournisseurs exposent une session collante en l'encodant dans le nom d'utilisateur du proxy, donc la sortie reste fixe pendant une fenêtre choisie.
Choisissez la granularité selon la tâche, pas selon la valeur par défaut du fournisseur. Un robot qui récupère des pages indépendantes peut tourner à chaque requête, tandis qu'un parcours de paiement ou une API authentifiée doit garder une sortie pendant tout le parcours. Les deux appels ci-dessous montrent un nom d'utilisateur collant et un point de terminaison rotatif simple, et le socks5h schéma résout les noms au niveau du proxy plutôt que localement.
curl -sS -x http://user-session-a1b2:[email protected]:8080 https://ifconfig.me
curl -sS -x socks5h://127.0.0.1:1080 https://ifconfig.meLe DNS local est une fuite silencieuse. Si le client résout le nom avant de se connecter, le résolveur apprend quand même chaque hôte que vous visitez même si la requête HTTP sort ailleurs. La socks5h forme et la résolution côté proxy évitent cela, et les utiliser ne coûte rien.
Ce que la cible classe en plus de l'adresse
La réputation d'une adresse est une entrée parmi plusieurs. Les cibles combinent l'ASN et son étiquette centre de données ou résidentielle, l'empreinte TLS du client, les réglages HTTP/2, l'ordre des en-têtes, le débit des requêtes et la forme de la navigation. Une sortie résidentielle pilotée par un navigateur sans interface peut échouer là où une sortie de centre de données pilotée par une vraie session passe.
Le type de sortie fixe ce que vous pouvez affirmer honnêtement sur le trafic, et chacun porte un coût différent.
| Exit type | What the target sees | Main cost |
|---|---|---|
| Datacenter proxy | Hosting ASN, cheap, often pre-blocked | Low reputation, easy to detect |
| Residential network | A consumer ISP address belonging to someone else | Consent and terms-of-service exposure |
| Mobile carrier | A carrier NAT address shared by many subscribers | Price, plus shared blame for abuse |
| Your own cloud egress | An address you are accountable for | Recognisable, but defensible |
Une sortie partagée n'est pas neutre. Tout ce qui d'autre tourne depuis cette adresse atterrit dans le même seau de réputation, et une adresse déjà brûlée par d'autres locataires échoue avant que votre première requête soit lue.
Choisissez une sortie que vous pouvez décrire dans une politique
La question utile n'est pas comment cacher l'adresse mais qui est responsable du trafic qui en sort. Votre propre sortie cloud par tâche, un fournisseur sous contrat avec un accord de traitement des données et une conservation publiée, et un VPN auto-hébergé avec une identité par tâche sont tous descriptibles en une phrase. Une liste gratuite ne l'est pas, car son opérateur n'a aucune obligation envers vous et toutes les incitations à journaliser.
Gardez vos propres limites de débit sous ce que la cible tolère, et ne collectez que les champs dont la tâche a besoin, pour qu'une erreur reste petite. Tourner plus vite pour échapper à un blocage augmente souvent le débit de requêtes qui l'a causé.
Écrivez la sortie choisie, sa fenêtre de rotation et son propriétaire dans la configuration du travail avant la première exécution. Quand le blocage arrive, cette note est ce qui vous dit s'il faut changer la sortie ou changer le comportement.