Commande à distance de Kaffeine

[Pulsar33]

Bonjour,

Ce message s'adresse surtout à k3c et à toute personne ayant des connaissances validées concernant iptables sous Linux ainsi que les WiFi Access Point sur smartphone. J'ai codé un paire client-serveur destinée à gérer Kaffeine à distance lorsque je suis loin de chez moi. Cette paire est totalement validée sur réseau local et partiellement sur réseau distant mais la dernière étape échoue. Le client dispose d'une interface graphique (gtk) "au poil" pour lister les chaînes, lister et modifier les enregistrements programmés, démarrer/arrêter Kaffeine, démarrer/arrêter l'enregistrement immédiat, et même post-traiter les enregistrements sur le serveur (celui qui a Kaffeine et les clés USB-TNT) pour compresser et faire de la place. Voici l'état actuel de l'outil :

Kmote-v1.0.png (40.13 Kio) Vu 9643 fois

Le PC fixe lui, fait tourner un serveur sans interface graphique qui filtre les commandes reçues (faut quand même pas accepter n'importe quoi) et intervient sur la base de données (sqlite) des enregistrements et des chaînes, sur le fonctionnement de Kaffeine et sur le dossier où sont enregistrées les vidéos afin de les traiter ou supprimer selon le besoin.

Comme indiqué plus haut, tout ceci fonctionne parfaitement sur le réseau local au moyen de datagram udp sur des ports dédiés, en utilisant par exemple un de mes Pi4 pour faire tourner le client et communiquer avec mon fixe. Le problème est le suivant : en déplacement, je ne peux pas compter sur une box inconnue ou même d'un ami car il faudrait que je modifie le routage de services, ce qui n'est pas souhaitable ou impossible. La solution simple est donc d'utiliser mon smartphone comme "box" en ouvrant l'Access Point WiFi (ce qui fonctionne parfaitement pour des consultations internet par exemple). Mon smartphone fonctionne sous Linux lui aussi (BQ Aquaris E5 édition Ubuntu Touch et/ou le même avec l'OS UBports qui en est le successeur). Il m'est donc tout à fait possible de lancer les commandes iptables nécessaires dans un terminal, et là, c'est le drame ...

Je poste déjà ceci et je poursuis ci-dessous ...


Linux 64 bits / France / Google Chrome 104.0.51

[Pulsar33]

J'ai bien évidemment posté mon problème sur le forum UBports considérant qu'il est lié de près au fonctionnement de l'Access Point WiFi qui tourne sur le smartphone mais je n'ai malheureusement aucune réponse après plusieurs messages (constructifs) et plusieurs jours. J'ai fouillé le net et appliqué les différentes gestions iptables qui me semblaient judicieuses sans succès. Pour vous montrer où ça coince, voici un schéma de principe plus clair que des mots :

UDP client server problem.png (266.75 Kio) Vu 9641 fois

ifconfig sur le smartphone m'indique que l'interface de l'Access Point est ap0 et que l'interface FAI est ccmni0. L'Access Point attribue 10.42.0;59 à ma Pi4. A cet instant de mon point de vue, pour que les paquets arrivant par ccmni0 sur le port YYYYY soient routés vers la Pi4 en 10.42.0.59 sur ce même port, il faudrait ajouter cette règle :
iptables -t nat -A PREROUTING -p udp -i ccmni0 --dport YYYYY -j DNAT --to-destination 10.42.0.59:YYYYY

Mais ça ne fonctionne pas. Les demandes de mon client partent et arrive au serveur, qui les traite et répond à l'adresse ip qui lui a été communiquée : celle du smartphone (de ce point de vue, mon schéma n'est peut-être pas totalement conforme)
Et là, peau de balle, ça n'arrive pas à la Pi4. Je ne sais pas tracer sur le smartphone (genre wireshark) et je n'en sais donc pas plus ...

Si quelqu'un pouvait m'indiquer quelles pistes explorer ce serait sympa !
Cordialement
Pulsar33


Linux 64 bits / France / Google Chrome 104.0.51

[Pulsar33]

Bonjour,

Finalement, le problème ne semble pas tant lié à l'Access Point qu'à la liaison 3G elle-même. En effet, j'ai compilé mon Client sur le téléphone. Je l'ai lancé directement et non sur une Pi4 reliée par WiFi au téléphone. Et bien le problème est exactement le même. Il ne s'agit donc pas d'un problème de transfert de ccmni0 vers ap0. Le message retourné par le serveur ne sort pas de l'interface ccmni0 (3G)

screenshot20220925_104551911.png (58.16 Kio) Vu 9541 fois

Lorsque je sélectionne le réseau local tel que sur l'image ci-dessus, tout fonctionne parfaitement. Mon téléphone pilote Kaffeine sur mon PC fixe sans problème. Mais si je coupe le réseau local et tente de passer par la 3G, le message arrive au serveur via son adresse ddns, le serveur répond (validé par WireShark) mais la réponse n'arrive pas sur le téléphone. Les règles iptables sont vides par défaut, ce qui suffit à fonctionner sur le réseau local. Via la 3G, il devrait en être de même pour une utilisation par le téléphone lui-même mais ça échoue. Et si j'ajoute des règles spécifiques (genre INPUT --dport YYYYY -j ACCEPT), rien de mieux ne se produit.

J'y perds mon latin
Une idée ?
Pulsar33


Linux 64 bits / France / Google Chrome 104.0.51

[czmaster]

Salut,

Je ne sais pas si j'ai bien compris, mais ce que tu veux c'est accéder à un port de ton RPI4 en local depuis un réseau distant, par exemple depuis ton smartphone.

Je n'utilise pas Kaffeine, mais j'accède à un RPI4 en externe sans manipulation d'Iptable.
Si tu y accèdes en local sur 192.168.0.32:33600, le seul paramètre auquel tu devrais toucher à mon avis c'est le NAT (ou redirection de port) sur ta box.

Exemple

IP destination 192.168.0.32
Début et fin identique : par exemple 33600
Port destination 33600
TCP

Ensuite tu y accèdes avec ton IP publique ou ton DynDNS, exemple dyndns.com:33600


Windows 10 64 bits / France / Firefox 104.0 64 bits

[Pulsar33]

Bonjour czmaster,

Merci de tenter de m'aider. Tu as bien saisi le point où ça coince mais pas le contexte global du problème. Regarde (déplie complètement) le grand schéma de principe du deuxième message de ce fil.

Sur la gauche, les flèches descendantes représentent le flux du Client (qui tourne sur la Pi4) vers le Serveur ddns (qui tourne sur mon PC fixe). Cette partie de la communication fonctionne très bien et pour ce faire, j'ai en effet ajouté une règle NAT qui permet aux paquets de passer de ma Box vers mon PC fixe.

Sur la droite, les flèches montantes représentent la réponse du Serveur au Client. J'ai pu tracer la réponse de mon PC, le passage à travers ma Box, et je n'ai aucune raison a priori de suspecter l'ISP de ne pas propager cette réponse jusqu'à mon smartphone, même si là je ne sais pas le tracer. La différence ensuite est que dans ce sens, c'est mon smartphone (Linux) qui sert de Box. Il convient donc de lui ajouter une règle NAT pour que le paquet soit transmis à la Pi4. C'est ce que j'ai fait également mais sans succès (commentaire sur fond rose dans le schéma).

Je croyais donc que le problème venait de la prise en compte des règles iptables au sein de mon smartphone. Mais (dernier message ci-dessus) je m'aperçois que ce n'est sans doute pas le cas. En effet, j'ai compilé l'application sur le smartphone et je la fais tourner directement sur celui-ci, évitant donc l'étape de re-routing Smartphone => Client Pi4. En théorie, l'application se mettant à l'écoute du port, il ne devrait même pas y avoir besoin de règle iptables et pourtant ça ne passe pas. J'ai même essayé (au cas où) d'ajouter une règle ACCEPT forçant l'ouverture du port mais ça ne change rien. Le paquet n'arrive pas.

Je me demande finalement si l'ISP joue bien le jeu et ne filtre pas certains ports (33600 n'est qu'un exemple, j'en ai essayé d'autres mais je n'ai peut-être pas eu de chance), d'autant plus que comme indiqué, si je passe par le réseau local tout fonctionne que ce soit depuis la Pi4 ou depuis le Smartphone. Où alors il y a un problème que je ne vois pas. D'où mes explications et questions ici comme sur le forum UBports (qui ne me répond pas sur ce sujet)

J'espère que c'est plus clair. Bonne journée
Pulsar33


Linux 64 bits / France / Google Chrome 104.0.51

[czmaster]

J'avoue ne pas maîtriser ton smartphone linux, n'importe quel autre smartphone utilisé comme point d'accès laisserait passer tous les flux et tous les ports.

Déjà est ce que depuis un PC sur un autre réseau tu arrives à accéder à ton port 33600, par exemple en faisant un telnet ?
Sur un PC distant ou faute de mieux sur ton smartphone Linux ?

Si tu n'y arrives pas le problèmes viens de ta règle NAT ...


Windows 10 64 bits / France / Firefox 104.0 64 bits

[Pulsar33]

Bonjour,

n'importe quel autre smartphone utilisé comme point d'accès laisserait passer tous les flux et tous les ports.

Es-tu bien sûr de celà ? Un smartphone en Access Point te permet sans nul doute de surfer mais de là à faire ce que tu veux sur n'importe quel port, je ne sais pas.

Pour information, sur le mien, aucune règle iptables n'est active si l'Access Point n'est pas en marche. Lorsque je démarre l'Access Point, les règles suivantes s'ajoutent automatiquement (et disparaissent quand j'arrête l'Access Point) :

Code: Tout sélectionner

*nat
-A POSTROUTING -s 10.42.0.0/24 ! -d 10.42.0.0/24 -j MASQUERADE
*filter
-A INPUT -i ap0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i ap0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i ap0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i ap0 -p tcp -m tcp --dport 53 -j ACCEPT
-A FORWARD -d 10.42.0.0/24 -o ap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.42.0.0/24 -i ap0 -j ACCEPT
-A FORWARD -i ap0 -o ap0 -j ACCEPT
-A FORWARD -o ap0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i ap0 -j REJECT --reject-with icmp-port-unreachable

L'ajout manuel d'une ou deux règles ci-dessous en tête de table sur le smartphone ne résout pas le problème

Code: Tout sélectionner

*nat
-A PREROUTING -i ccmni0 -p udp -m udp --dport 33600 -j DNAT --to-destination 10.42.0.59:33600
*filter
-A FORWARD -d 10.42.0.59/32 -i ccmni0 -p udp -m udp --dport 33600 -j ACCEPT

Déjà est ce que depuis un PC sur un autre réseau tu arrives à accéder à ton port 33600, par exemple en faisant un telnet ? Sur un PC distant ou faute de mieux sur ton smartphone Linux ? Si tu n'y arrives pas le problèmes viens de ta règle NAT ...

Comme indiqué la communication avec le port 33600 :
- fonctionne dans le sens Pi4 => Smartphone => ISP => Box => PC (la règle NAT de la box est donc bonne)
- ne fonctionne pas dans l'autre sens entre l'ISP et la Pi4 (raison inconnue à ce stade, ISP suspecté)

Je croyais donc que le problème venait de la prise en compte des règles iptables au sein de mon smartphone. Mais [...] je m'aperçois que ce n'est sans doute pas le cas

Il faut que je trouve une box avec laquelle je puisse faire l'essai Pi4 => PC => Pi4 pour éviter de passer par la 3G. Je crois que c'est le seul moyen pour lever le doute concernant l'ISP. Mais les proches qui ont une box sont plutôt "frileux" à propos des bidouilles informatiques ...

Bonne journée
Pulsar33


Linux 64 bits / France / Google Chrome 104.0.51

[Pulsar33]

Bonsoir,

n'importe quel autre smartphone utilisé comme point d'accès laisserait passer tous les flux et tous les ports.

Es-tu bien sûr de celà ? Un smartphone en Access Point te permet sans nul doute de surfer mais de là à faire ce que tu veux sur n'importe quel port, je ne sais pas

Je viens d'essayer avec un Fairphone2 sous Androïd qui passait par là, j'ai exactement les mêmes constats, sauf que je ne peux pas aller voir "dedans" ce qu'il se passe mais je ne crois pas que j'en apprendrais plus qu'avec le mien.
J'ai de plus en plus de doute sur l'ISP. Les deux téléphones ont des contrats différents mais chez le même FAI. Qu'en est-il vraiment ??? Mystère !

Bonne soirée
Pulsar33


Linux 64 bits / France / Google Chrome 104.0.51

[Pulsar33]

Bonjour,

Voici une réponse reçue sur le forum UBports :

De nombreux opérateurs mobiles mettent en œuvre la norme CGNAT et l'adresse externe affichée par les sites Web n'appartient pas à l'appareil, mais à la passerelle NAT gérée par le FAI. Ne faites donc pas confiance à l'adresse si vous ne la voyez pas sur l'appareil lui-même.

En outre, la plupart des opérateurs de téléphonie mobile ne fournissent pas d'adresses IP dédiées - ils effectuent du NAT "1:many", et pas seulement du NAT 1:1, et l'adresse externe est utilisée simultanément par plusieurs clients (tout comme votre routeur domestique partage vos adresses externes entre tous les appareils du réseau local).

Même les opérateurs qui dédient une adresse par client (qu'elle soit directe ou NAT 1:1) la placent souvent derrière un pare-feu qui bloque toutes les connexions entrantes. Cela a deux objectifs : empêcher le client d'héberger des services sur sa connexion 4G (ce qui n'est généralement pas autorisé par les conditions de service) et empêcher les divers scans de botnet et les connexions non sollicitées de vider la batterie de l'appareil.

Ça sent pas bon ...
Pulsar33


Linux 64 bits / France / Google Chrome 104.0.51

[k3c]

tu peux installer termux sur ton téléphone, mais il faudra "rooter" ton téléphone pour faire l'équivalent de

netstat
ou
ss

pour voir ce qui circule en clair, vu que /proc est verrouillé

Ou alors tu peux utiliser ADB
https://fr.wikipedia.org/wiki/Android_S ... bug_Bridge
et alors tu as
https://adbshell.com/commands/adb-shell-netstat


Linux 64 bits / France / Firefox 102.0