Je suppose que même en IPv6 la majorité des "box" et autres passerelles seront configurées pour autoriser les connexions sortantes et bloquer les entrantes.
Là j'avoue que je ne sais pas trop ce qu'il en sera ... Effectivement, vu la fiabilité des machines sous l'OS de MS quand elles sont directement exposées au net, il est probable que le firewall soit configuré pour tout bloquer par défaut. Mais j'espère qu'on pourra au moins facilement désactiver ce truc (voire sélectivement).
Un subnet de quel réseau ?
Du préfixe qui t'est attribué par ton FAI. En général, tu as un minimum un /56, t'as donc de la place pour créer ce que tu veux ...
Si c'est un nouveau réseau, le routage local sur sa machine n'aurait pas suffit. Les passerelles intermédiaires n'auraient pas connaissance de ce subnet.
Les gens habitués à IPv4 pensent toujours à "sous-réseau privé" : non, là on fera un sous-réseau public, routable.
Et la conf d'un subnet et de règles de routage est autrement plus délicate à faire faire à distance à un utilisateur qu'un :
ssh -R1234:localhost:22 toto@monrelais.com
La conf d'un masquerading est aussi "compliquée" que la conf d'un subnet. Sauf que c'est fait automatiquement par ta box ou le script de montage de ta VM. Et bah là ce sera pareil avec le subnet. C'est juste que maintenant il n'y aura plus de tunnel à faire. Moi, j'en conclue "plus simple".
En dépannage, la bidouille c'est souvent ce qui te sauve la vie !
Oui, effectivement, ce dont je parlais valais plutôt dans un cas "général". Quand tu dois rapidement dépanner quelqu'un, tu fais avec ce que tu as. Forcément, là, tu n'avais pas d'IPv6, mais si c'était plus répandu ...
Dans le cas présent, on a pu reconstruire une image de 10 Go à distance et malgré plusieurs coupures WiFi (merci SSH+screen).
Là je pense que tu peux surtout dire merci à TCP (et screen quand ça coupe vraiment). SSH n'a rien à faire là-dedans, et ça marcherait aussi bien sans tunnel avec IPv6.
[^] # Re: Incontournable
Posté par benoar . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 3.
Là j'avoue que je ne sais pas trop ce qu'il en sera ... Effectivement, vu la fiabilité des machines sous l'OS de MS quand elles sont directement exposées au net, il est probable que le firewall soit configuré pour tout bloquer par défaut. Mais j'espère qu'on pourra au moins facilement désactiver ce truc (voire sélectivement).
Un subnet de quel réseau ?
Du préfixe qui t'est attribué par ton FAI. En général, tu as un minimum un /56, t'as donc de la place pour créer ce que tu veux ...
Si c'est un nouveau réseau, le routage local sur sa machine n'aurait pas suffit. Les passerelles intermédiaires n'auraient pas connaissance de ce subnet.
Les gens habitués à IPv4 pensent toujours à "sous-réseau privé" : non, là on fera un sous-réseau public, routable.
Et la conf d'un subnet et de règles de routage est autrement plus délicate à faire faire à distance à un utilisateur qu'un :
ssh -R1234:localhost:22 toto@monrelais.com
La conf d'un masquerading est aussi "compliquée" que la conf d'un subnet. Sauf que c'est fait automatiquement par ta box ou le script de montage de ta VM. Et bah là ce sera pareil avec le subnet. C'est juste que maintenant il n'y aura plus de tunnel à faire. Moi, j'en conclue "plus simple".
En dépannage, la bidouille c'est souvent ce qui te sauve la vie !
Oui, effectivement, ce dont je parlais valais plutôt dans un cas "général". Quand tu dois rapidement dépanner quelqu'un, tu fais avec ce que tu as. Forcément, là, tu n'avais pas d'IPv6, mais si c'était plus répandu ...
Dans le cas présent, on a pu reconstruire une image de 10 Go à distance et malgré plusieurs coupures WiFi (merci SSH+screen).
Là je pense que tu peux surtout dire merci à TCP (et screen quand ça coupe vraiment). SSH n'a rien à faire là-dedans, et ça marcherait aussi bien sans tunnel avec IPv6.