Forum Linux.général Connecter une interface à un port

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
19
avr.
2021

Bonjour,

Je vous expose mon problème, sur ma Raspberry je possède 2 interfaces réseaux branchés :

Wlan0 = Wifi de ma box
Eth1 = Clef 4G

J'ai donc ouvert mon port 22 afin de pouvoir administrer ma raspberry à hors réseau local, malheureusement dès que je branche ma clef 4G, impossible de me connecter à ma raspberry hors de mon réseau local.

Ma question est la suivante, est il possible de lié l'interface Wlan0 au port 22 afin de pouvoir me connecter à ma raspberry hors de mon réseau local même quand ma clef 4G est branchée.

Si vous avez d'autres idées afin d'arriver au même résultat je suis bien évidemment preneur :)

Je vous souhaite une bonne journée et j'éspère que vous pourrez m'aider.

  • # configuration du serveur ?

    Posté par  . Évalué à 3.

    probablement, un parametre du serveur à modifier : /etc/ssh/sshd_config : ListenAddress = 0.0.0.0

    suivi d'un systemctl reload ssh

  • # route par defaut ?

    Posté par  . Évalué à 3.

    un probleme de routage ?

    quand tu n'as pas la carte 4G, ta route par defaut est sur le wifi/LAN
    quand tu branches la carte 4G, la route par defaut est modifiée et sort par la 4G (ou pas)

    si tu tentes de te connecter en SSH via la 4G, alors que la route par defaut est toujours par le wifi, tu as ce que l'on appelle du routage asymétrique (entrée par une interface, retour par une autre)

    • [^] # Re: route par defaut ?

      Posté par  . Évalué à 1.

      Je te remercie pour ta réponse.

      Ce que tu as dis est très intéressant, en revanche je tente toujours de me connecter en SSH via l'ip de ma box et jamais par la 4G qui est vouée à faire proxy et donc à changer d'ip régulièrement.

      quand je fais un iproute, voila le résultat :

      default via 192.168.8.1 dev eth1 proto dhcp src 192.168.8.100 metric 203
      default via 192.168.1.254 dev wlan0 proto dhcp src 192.168.1.51 metric 304 mtu 1500
      192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.51 metric 304 mtu 1500
      192.168.8.0/24 dev eth1 proto dhcp scope link src 192.168.8.100 metric 203

      192.168.1.0 = box
      192.168.8.0 = clef 4G

      Est-ce que je peux lock la route par défaut sur ma box ?

  • # mauvaise conceptualisation ^^

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Les ports ne sont pas liés spécifiquement aux interfaces…

    Il faut par contre que ton service (qui utilise donc ce port, ici SSHd) écoute sur l'adresse qui t'intéresse (et chaque interface active porte une adresse …au moins) En prime, pour certains services (ssh/http/etc.) il faut que la résolution de nom concorde…
    Il faut aussi que ton parefeu (ou un autre sur le chemin) ne bloque pas le trafic qui t'intéresse.

    Donc, pour commencer, vérifies bien comment tu te connectes de l'extérieur Raspberry : utilises-tu bien l'IP WAN ? et si c'est par le nom, est-ce résolu ? Ensuite, ton IP WAN est géré comment ? (normalement une clé 4G est un/une routeur/passerelle qui par défaut n'autorise pas de trafic entrant —certains FAI peuvent même limiter les services auxquels on a accès…— il faut regarder au niveau de son interface web comment activer et configure le NAT… ou juste le firewall ?)

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: mauvaise conceptualisation ^^

      Posté par  . Évalué à 5.

      exact, j'ajouterais que parfois les reseaux 3G/4G/5G ne fournissent pas réellement une IP publique,

      si tu fais un traceroute vers l'extérieur via cette connexion, on voit qu'on traverse plusieurs réseaux privés (10.x.y.z, 172.16.x.y, 192.168.x.y) avant de sortir.

      dans ce genre de situation, c'est un peu comme chez toi,
      tes PCs sont sur un reseau privé, et ta box cache les PCs derriere l'IP publique de la box

      si tu veux rentrer sur un de tes PCs, il faut configurer la box pour transférer le port extérieur vers l'IP du PC visé.

      avec ton FAI 4G, tu as rarement la possibilité de modifier leur box/firewall

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: mauvaise conceptualisation ^^

        Posté par  (Mastodon) . Évalué à 2.

        exact, j'ajouterais que parfois les reseaux 3G/4G/5G ne fournissent pas réellement une IP publiqu

        il est bien là le soucis : impossible d'accéder depuis l'extérieur à un périphérique en 4G. en tous cas pas en France où tous les opérateurs donnent une IP non routable (IP de réseua local, on est derrière un NAT quoi).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: mauvaise conceptualisation ^^

          Posté par  . Évalué à 3. Dernière modification le 19 avril 2021 à 10:21.

          faut tricher avec un bastion/vpn ou bastion/ssh
          tes machines 4G se connecte via le VPN ou en ssh
          et toi tu viens chercher le bastion/vpn(ssh) pour remonter sur les machines.

          • [^] # Re: mauvaise conceptualisation ^^

            Posté par  (Mastodon) . Évalué à 2.

            exact, mais ce n'est en rien une "triche", c'est comme ça qu'il faut faire (et c'est comme ça que je fais via un serveur OVH à pas cher).

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: mauvaise conceptualisation ^^

      Posté par  . Évalué à 1.

      Merci pour ta réponse.

      Il faut donc que je fasse écouter le service SSHd sur l'adresse de ma box?

      Mon but est vraiment de continué à me connecter via ma box sur la Raspberry (pour le SSH).
      J'y arrive très bien dès que ma clef 4G est débranchée, je suppose donc que la configuration de ma box est bonne.

      • [^] # Re: mauvaise conceptualisation ^^

        Posté par  . Évalué à 4.

        donc il faut te pencher sur le "routage asymétrique"

        tu arrives par l'IP publique de ta box (qui redirige un port vers ton RPi)
        mais avec la clef 4G, sa route de sortie par defaut doit basculer sur le FAI 4G, donc les réponses à ta demande SSH partent dans la 4G, et pas dans le WIFI

        ta box ne faisant pas de NAT quand tu arrives de l'extérieur, c'est un peu compliqué à mettre en place.

        • [^] # Re: mauvaise conceptualisation ^^

          Posté par  . Évalué à 1.

          C'est le problème des trucs "plug and play" prévu pour un usage "courant" et qui simplifie la vie à la plupart des gens qui utilisent un ordinateur. Dès que tu sors des clous ça devient plus compliqué, et ces ensembles de couches/surcouches en général ne simplifient pas la vie (car elles prétenent savoir mieux que toi ce que tu veux faire).

          A mon avis lorsque tu plug ta clé usb sur ton raspberry, le système va modifier la route par défaut et la remplacer par celle qui est fourni par ton provider. Du coup comme précisé tu vas te retrouver avec un routage asymétrique.

          Essaie de noter la route par défaut que tu as quand tu as débranché ta clé, puis ensuite regarde ce qui se passe lorsque tu la rebranche. Du coup il faudrait peut-être modifier les paramètres de connection de l'interface correspondant à ta clé 4G pour que le dhcp ne force pas la route par défaut ( je pense que ça doit être possible, tout au moins via certaines interfaces de configuration réseau).

          Pour la route je préfère largement la commande netstat (avec le switch -nr à la commande ip route qui est une linuxerie, et qui ne fournit pas forcément les infos dont on a besoin).

          • [^] # Re: mauvaise conceptualisation ^^

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            Euh… Y a une comme une confusion dans ton dernier paragraphe…

            • ip r (en fait l’abréviation de ip route show ou ip route list qui sont la commande par défaut) est la linuxerie équivalente à route (avec l'option linuxienne -e pour l'afficher au format NetStat, d'où la confusion ?)
            • ss (dans le même paquet IP2) est la linuxerie équivalente à netstat et tous deux ont les mêmes options standard…

            Les deux paires n'ont pas le même objectif…

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: mauvaise conceptualisation ^^

              Posté par  . Évalué à 1.

              Merci pour les précisions. Il est fort possible que les options de la commande ip permettent d'avoir le même résultat que la commande netstat, mais quand on passe d'un système à un autre (Linux/xBSD essentiellement, avec de temps en temps du passage sur du HP-UX, aix et solaris - ce qui ne m'est plus arrivé depuis un moment pour les 3 derniers - on préfère utiliser le tronc commun …

              Sinon la différence entre ip route et netstat -nr :

              
totof@superbipbip:~$ ip route
default via 192.168.19.254 dev eno2 proto dhcp metric 100
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown
169.254.0.0/16 dev crc scope link metric 1000 linkdown
192.168.19.0/24 dev eno2 proto kernel scope link src 192.168.19.4 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
192.168.130.0/24 dev crc proto kernel scope link src 192.168.130.1 linkdown
192.168.250.0/24 dev anbox0 proto kernel scope link src 192.168.250.1

totof@superbipbip:~$ netstat -nr qui correspond à la commande 
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic   MSS Fenêtre irtt Iface
0.0.0.0         192.168.19.254  0.0.0.0         UG        0 0          0 eno2
10.0.3.0        0.0.0.0         255.255.255.0   U         0 0          0 lxcbr0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 crc
192.168.19.0    0.0.0.0         255.255.255.0   U         0 0          0 eno2
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
192.168.130.0   0.0.0.0         255.255.255.0   U         0 0          0 crc
192.168.250.0   0.0.0.0         255.255.255.0   U         0 0          0 anbox0
totof@superbipbip:~$

              ss (dans le même paquet IP2) est la linuxerie équivalente à netstat et tous deux ont les mêmes options standard…

              Pourquoi avoir réécrit une commande différente J'ai du mal à comprendre la raison …. Cela dit tant qu'on ne remplace pas tout ça par une commande systemctl route list par exemple, et qu'on garde la possibilité d'utiliser les deux (avec un alias entre ss et route) , pourquoi pas ?

              • [^] # Re: mauvaise conceptualisation ^^

                Posté par  . Évalué à 1. Dernière modification le 28 avril 2021 à 12:03.

                Un truc qui me vient à l'esprit (je fork le thread sépare le fil de discussion pour éviter de tout mélanger) … Puisqu'on vire les branches master de Git, pourquoi garde-t-on la commande ss qui pourrait choquer des juifs, polonnais, ou toute autre personne descendant de victimes des nazis ?

              • [^] # Re: mauvaise conceptualisation ^^

                Posté par  . Évalué à 2.

                peut)etre parce que netstat/ss ne permet pas de configurer les adresses IP
                là ou la commande ip permet de gérer les IP, les routes, les routes-rules

              • [^] # Re: mauvaise conceptualisation ^^

                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                On s'est mal compris…
                C'est netstat -r qui a le même formatage que route (avec -n ayant le même sens pour les deux.) enfin quasiment (sous GNU/Linux c'est plus précisément route -e et cette option n'est pas reconnue partout et l'affichage peut différer légèrement d'un Unix-like à un autre —vécu)
                Je disais que pour afficher et manipuler les tables de routage, ip r remplace maintenant route dans les distributions GNU/Linux.
                Je faisais remarquer que indirectement que netstat et son pendant ss eux affichent les connexions actives. (Oui, avec l'option -r qui bien que connu un peu partout mais n'est pas POSIX —de mémoire—, netstat peut afficher la table de routage aussi)

                Pourquoi avoir réécrit une commande différente

                Je pense que ce que le besoin de pouvoir monitorer les connexions ouvertes justifie d'avoir une commande dédiée dans la nouvelle suite, et elle est très petite car réutilisant une bonne partie du code commun. Il fallait un autre nom parce-que ça ne supporte pas toutes les options pour prétendre faire office de drop replacement comme on dit.

                mais quand on passe d'un système à un autre […]

                Je suis bien d'accord, et c'est pour ça que je fais de moins en moins de Linux ou alors je passe par un cadriciel de type Ansible (plutôt que des scripts, mais on est d'accord que par contre en cours d'incident il faut s'adapter aux manchots qui ne veulent rien faire comme les autres)

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.