Partage de connexion Android / Mac impossible (VPN et proxy)

[ctob]

Partage de connexion VPN entre Android et Mac​

Local Nav Open Menu
Bonjour,

Je suis abonné à PureVPN que j'utilise sur mon téléphone Android et mon MacBook.

Le VPN est plus abouti pour Android, avec notamment l'Internet Kill Switch qui n'autorise pas de connexion tant que le VPN ne la prend pas en charge. Ce n'est pas le cas sur MacOS pour lequel IKS n'est pas opérationnel (info de la hotline PureVPN). Afin de bénéficier du VPN lorsque je suis sur un réseau public ou peu sécurisé, j'ai voulu passer par un partage de connexion Android / MacOS.

J'ai essayé d'utiliser Every Proxy sur Android afin que le Mac puisse partager la connexion VPN de mon téléphone Android. J'ai suivi point à point la documentation de Every Proxy, tenté un connexion HTTP/HTTPS puis SOCKS mais sans jamais arriver à ce que ça fonctionne. Every Proxy ne montre aucun flux entrant/sortant et il est impossible d'accéder à internet sur le Mac. J'ai également tenté chaque adresse IP de Every Proxy et de changer les ports mais sans succès.

Si quelqu'un a une solution je serais preneur, je ne sais absolument pas où peut se trouver le souci.

Je vous remercie,

CTob

 

[bunam]

Ce n'est pas ceci qui est recherché ?

 

[ctob]

Ce n'est pas ceci qui est recherché ?

Effectivement la case à cocher existe, mais n'est pas fonctionnelle pour MacOS...

Mais ceci est secondaire, j'aimerais arriver à faire fonctionner le partage entre le Mac et Android

 

[Polo35230]

Salut,

J'ai pas trop d'idées, mais sur le Mac, il faudrait faire quelques tests pour essayer de comprendre.

-On part du principe que tout est bon sur le smartphone, donc, que via le VPN, sur celui-ci, tu peux accéder à internet.

-Sur le Mac, tu as donc configuré le wifi pour accéder à celui du smartphone.
Vérifie quand même si le smartphone t'a bien attribué une adresse IP (appuie sur la touche "option", et clique sur l'icône wifi dans la barre des menus)
Regarde ensuite si, dans la configuration "Réseau--Wifi---Avancé" tu as bien coché "Proxy web" et renseigné les éléments donnés par Every Proxy (adresse IP, n° de port, et éventuellement le login/pasword)

-Si c'est le cas, dans une fenêtre du Terminal, fais un:
nslookup google.fr
puis un
traceroute AdresseIPduProxyWeb

On y verra peut-être plus clair...

 

[ctob]

Salut,

J'ai pas trop d'idées, mais sur le Mac, il faudrait faire quelques tests pour essayer de comprendre.

-On part du principe que tout est bon sur le smartphone, donc, que via le VPN, sur celui-ci, tu peux accéder à internet.

-Sur le Mac, tu as donc configuré le wifi pour accéder à celui du smartphone.
Vérifie quand même si le smartphone t'a bien attribué une adresse IP (appuie sur la touche "option", et clique sur l'icône wifi dans la barre des menus)
Regarde ensuite si, dans la configuration "Réseau--Wifi---Avancé" tu as bien coché "Proxy web" et renseigné les éléments donnés par Every Proxy (adresse IP, n° de port, et éventuellement le login/pasword)

-Si c'est le cas, dans une fenêtre du Terminal, fais un:
nslookup google.fr
puis un
traceroute AdresseIPduProxyWeb

On y verra peut-être plus clair...

Hello,

Merci beaucoup de ta réponse, j'ai tenté HTTP Injector au lieu de Every Proxy et c'est la même chose, voici le résultat du nslookup et traceroute (HTTP Injector une fois lancé a l'IP 192.168.123.117 sur le port 44355) :



Et en tentant un connexion via Chrome :

 

[Polo35230]

-Le nslookup est bon.
Le Proxy web du serveur VPN (192.168.123.117) est aussi serveur DNS, et il renvoie bien l'adresse IP de google.fr (142.250.74.27)
Donc, techniquement, tu as bien utilisé le tunnel VPN du smartphone, et le serveur VPN a bien résolu le nom de domaine.
-Le traceroute est bon jusqu'au serveur VPN. Là aussi tout va bien.
Le tunnel fonctionne en partage de connexion.

Pour voir si le pb est lié au navigateur (ou pas), peux-tu faire un ping du site macg.co dans une fenêtre du Terminal
ping macg.co -c 3
Puis un:
traceroute macg.co
Tu devrais avoir plusieurs lignes, puis 3 "" Les "" sont certainement dus à un firewall de macg qui interdit le protocole icmp.
Fais aussi un ping du site inaccessible chez toi
ping mail.google.com -c 3

-Si c'est bon, tu peux aussi simuler une connexion https à ce site partir du Terminal:
curl -I https://mail.google.com
Si c'est bon, le pb est lié au navigateur

 

[ctob]

-Le nslookup est bon.
Le Proxy web du serveur VPN (192.168.123.117) est aussi serveur DNS, et il renvoie bien l'adresse IP de google.fr (142.250.74.27)
Donc, techniquement, tu as bien utilisé le tunnel VPN du smartphone, et le serveur VPN a bien résolu le nom de domaine.
-Le traceroute est bon jusqu'au serveur VPN. Là aussi tout va bien.
Le tunnel fonctionne.

Pour voir si le pb est lié au navigateur (ou pas), peux-tu faire un ping du site macg.co dans une fenêtre du Terminal
ping macg.co -c 3
Puis un:
traceroute macg.co
Tu devrais avoir plusieurs lignes, puis 3 "" Les "" sont certainement dus à un firewall de macg qui interdit le protocole icmp.
Fais aussi un ping du site inaccessible chez toi
ping mail.google.com -c 3

-Si c'est bon, tu peux aussi simuler une connexion https à ce site partir du Terminal:
curl -I https://mail.google.com
Si c'est bon, le pb est lié au navigateur

Merci Voilà le résultat des commandes (j'ai interrompu le traceroute à la quinzième ligne) :

 

[Polo35230]

Ben, tous les tests via le Terminal sont bons...
Le traceroute montre que tu arrives bien chez OVH, qui doit être l'hébergeur de macge.
Le dernier test (le curl) montre que tu as bien pu faire une connexion HTTPS à mail.google.com à partir du Terminal.
Ça devrait marcher...

Dans la barre d'adresse de Chrome, tape mail.google.com
Le curl a marché. La connexion https s'est bien faite, donc, logiquement, via la barre d'adresse d'un navigateur, ça devrait aussi marcher.
Si tu as des extensions dans Chrome, il faudrait peut-être aussi les désactiver pour voir...

Si la page d'accueil ne s'affiche pas avec Chrome, peux-tu essayer avec un autre navigateur (Safari, Firefox) pour voir si c'est bon?

 

[ctob]

Alors, roulement de tambour : Chrome KO, Firefox KO, Safari KO mais...



Avec Lynx ça fonctionne...

J'édite et modère : il n'y a que Google qui fonctionne avec Lynx, d'autres sites affichent une erreur de sécurité et de certificat. Peut-être que Google fonctionne dû au fait que j'ai autorisé cloud.google.com pour pouvoir utiliser Google Drive avec rclone (mais étrange que ça ne fonctionne pas avec Chrome par exemple).

 

[Polo35230]

Là, je dois dire que j'ai du mal à comprendre...

Le tunnel VPN marche.
À partir du smartphone, c'est bon, MAIS en partage de connexion, via les navigateurs classiques, ça ne marche pas, alors qu' avec Lynx (je ne connaissais pas), on a un retour. Même si c'est pas terrible :banghead:

-Un truc quand même: Lynx est en mode texte, et quand je regarde ta copie d'écran , je vois que les caractères accentués ne sont pas affichés (recherche avanc, Actualit , par exemple)
-On peut remarquer aussi que dans les commandes du Terminal et leurs réponses sont en mode texte sans accent, et ça passe...

On peut peut-être penser qu'il y a un pb de codage (UTF-8, ISO 8851-1 par exemple) Un caractère accentué est sur 8 bits, un caractère non accentué est sur 7 bits (mais avec un bit de parité)
Ce qui pourrait expliquer aussi la palanquée de pb du genre certificats ou autres...

Je n'utilise pas de VPN. Dans la conf du tien, dans la partie partage, il n'y a rien qui parle du codage?
Ceci dit, je ne comprendrai pas bien pourquoi le partage de connexion sur le smartphone change quoique ce soit à ce niveau.

Bref, je patauge :siffle:

 

[totoguile]

C'est pas un problème de MTU ? Essayez de la forcer à 1418 sur votre mac.

 

[Polo35230]

C'est pas un problème de MTU ? Essayez de la forcer à 1418 sur votre mac.

Alors oui, et là, on reconnait les anciens du réseau (?) à l'époque ou les serveurs ne prenaient pas en compte les connexions via un Tunnel et laissaient 1500 (au lieu de la baisser pour prendre en compte l'overhead dû au tunnel)
En principe, la valeur de la MTU est négociée au plus bas entre le client et le serveur lors de la connexion TCP.
Mais on est dans un contexte un peu particulier (partage/VPN, double connexion due au Proxy), et ça vaut le coup de faire le test.
D'autant plus que dans les tests via le Terminal, autant dans les requêtes que dans les réponses, les segments TCP sont courts...

Question:
Avec Chrome, en mode partage, mais sans le VPN, C'est bon?
Parce que, si c'est bon, et si la solution de @totoguile ne marche pas, je mettrai bien en cause l'encodage au niveau HTTP (l'histoire des voyelles avec accents dans Lynx). Mais là, j'y connaît rien...

 

[totoguile]

Alors oui, et là, on reconnait les anciens du réseau (?)

@Polo35230 si tu savais
Disons que lorsque j'étais encore à l'exploitation du backbone d'un opérateur, on avait mis des jumboframe à 2000 pour éviter tous ces problèmes

 

[Polo35230]

Les jumbo frames, je les ai connues à 6000. Autant dire que si, sur les liaisons chargées, il y avait des réémissions,
le gain en overhead était annulé par celles-ci...
Mais on s'éloigne du sujet

 

[ctob]

Je ne sais pas ce qu'est MTU, merci de la piste, je vais regarder.

 

[ctob]

Bon et bien ça ne fonctionne pas non plus en modifiant la valeur du MTU.

 

[ctob]

Question:
Avec Chrome, en mode partage, mais sans le VPN, C'est bon?
Parce que, si c'est bon, et si la solution de @totoguile ne marche pas, je mettrai bien en cause l'encodage au niveau HTTP (l'histoire des voyelles avec accents dans Lynx). Mais là, j'y connaît rien...

Désolé je n'avais pas vu la question : je n'avais pas pensé à faire ce test et arghhh oui ça fonctionne si le VPN n'est pas lancé avec les paramètres proxy o_O

 

[ctob]

Je n'utilise pas de VPN. Dans la conf du tien, dans la partie partage, il n'y a rien qui parle du codage?
Ceci dit, je ne comprendrai pas bien pourquoi le partage de connexion sur le smartphone change quoique ce soit à ce niveau.

Bref, je patauge :siffle:

Et non, on peut modifier UDP, TCP... mais la config avancée est assez pauvre, pas de choix d'encodage.

 

[Polo35230]

Au plus on avance dans le temps, au plus on approche de la solution ...

Donc, sans VPN, le partage marche (heureusement quand même!).
C'est donc le VPN qui est en cause.
Je pense que le pb est au niveau du serveur VPN (ou du paramètrage), et que c'est un pb d'encodage, au niveau http...

-Dans le client VPN, il faudrait tester d'autres serveurs VPN. Tu dois pouvoir changer de pays. Choisis un serveur en France, pour le test.

-Autrement, change de VPN.
CybetGhost par exemple (il y a une période d'essai gratuite)

 

[bunam]

Sur Mac il y a eu une MAJ pour pureVPN, on dirait qu'il n'y a plus de message concernant le kill switch (je n'ai pas expérimenté)