Si c'est assez facile (enfin sauf avec systemd qui autorise toutes les connexions TCP de base avant de dire (削除) pardon (削除ここまで)va te faire un peu plus tard). La carte réseau sait de base si le layer 2 est OK (toute seule comme une grande) ensuite en une commande arp et une commande TCP on peut savoir comment et ou on est connecté, si il y a l'internet derrière, si la route est stable etc.
Cas typique, vous êtes associé en wifi, mais le wifi sort pas, ou bien il y a un problème d'authent
Une fois de plus on sait faire (un arping par exemple sur un réseau avec plus d'une machine - ou même une bête trame icmp qui ne renverra pas la même erreur suivant que le réseau soit inaccessible ou introuvable) mais on ne fait pas car le gain est minime (enfin sauf networkd qui ne sait pas faire mais qui fait quand même parce que bon c'est trop cool de créer des dizaines d'entrées dans IPTables pour se vautrer au final)
Ensuite, lorsqu'on perd le réseau puis qu'on le retrouve, toutes les applications veulent se reconnecter, et patatras le bottleneck dans tes dents.
Alors à part un très gros serveur avec une masse de client et un admin facétieux qui s'amuse à débrancher et rebrancher le switch de distribution "pour rire" je vois pas. J'ai un (petit) pandaboard capable d'ouvrir plusieurs centaines de connexion TCP par seconde. Bon c'est vrai que Firefox a un peu tendance à bourriner en cas de reconnexion. Mais c'est plus un problème du logiciel Firefox que de Linux (genre lancer d'abord une petite dizaine de demandes de reconnexions avant de passer en mode berserk ca serait mieux). Dans la plupart des cas c'est juste que le programme devrait envoyer quelques demandes TCP avant d'estimer que là c'est bon le tuyeau est ouvert et qu'il peut se lacher (enfin sauf pulseaudio qui massacre déjà tellement la latence son avec son archi chaotique que si en plus il devait faire des tests avant d'ouvrir les trombes de connexions dont il a besoin on écouterait sa musique en morse)
Lorsqu'en plus tu as par malheur changé de timezone entretemps
Déjà évoqué plusieurs fois : il faut bosser en UTC - et un Linux bien installé travaille en UTC même si l'heure du bios est forcée sur Trinidad et Tobago. Les protocoles eux mêmes ne sont généralement pas sensibles à la référence de temps - excepté mDNS qui sur certaines implémentations par des fabricants par très malins peut avoir tendance à s'appuyer sur l'heure locale affichée pour générer des clefs de sécurité. Fort heureusement mDNS est un protocole local ce qui limite grandement la casse (enfin sauf avec Avahi qui possède une implémentation "reflector" qui permet de router un protocole non routable entre plusieurs réseaux qui ont éventuellement des timezones différentes - fou-rires assurés)
Vous me direz firewall, mais bon actuellement il faut tout droppper pour recharger des règles ce qui laisse un gap pour un attaquant.
Si tu connais déjà tes règles tu peux les ajouter et flagguer ta connexion elle même (genre écrire des règles de type - si je suis sur le réseau de José alors laisser passer tel type de connexion) Je l'ai fait quelquefois (avant de décider que définitivement IPTables c'était trop chiant à configurer pour moi) je le fais encore sous FreeBSD/OpenBSD en quelques lignes avec pf. Ca marche depuis des années sous Linux et plutôt bien (enfin sauf encore si vous avez networkd - là on ne peut plus rien pour vous et le département d'état tralala tsoin tsoin).
Donc non pas de vrai problème de mobilité avec Linux.
# Tout va très bien madame la Marquise
Posté par Kaane . En réponse au journal et le trolldi d'aujourd'hui est à?. Évalué à 10.
En gros, pas moyen de savoir si on est connecté
Si c'est assez facile (enfin sauf avec systemd qui autorise toutes les connexions TCP de base avant de dire
(削除) pardon (削除ここまで)va te faire un peu plus tard). La carte réseau sait de base si le layer 2 est OK (toute seule comme une grande) ensuite en une commande arp et une commande TCP on peut savoir comment et ou on est connecté, si il y a l'internet derrière, si la route est stable etc.Cas typique, vous êtes associé en wifi, mais le wifi sort pas, ou bien il y a un problème d'authent
Une fois de plus on sait faire (un arping par exemple sur un réseau avec plus d'une machine - ou même une bête trame icmp qui ne renverra pas la même erreur suivant que le réseau soit inaccessible ou introuvable) mais on ne fait pas car le gain est minime (enfin sauf networkd qui ne sait pas faire mais qui fait quand même parce que bon c'est trop cool de créer des dizaines d'entrées dans IPTables pour se vautrer au final)
Ensuite, lorsqu'on perd le réseau puis qu'on le retrouve, toutes les applications veulent se reconnecter, et patatras le bottleneck dans tes dents.
Alors à part un très gros serveur avec une masse de client et un admin facétieux qui s'amuse à débrancher et rebrancher le switch de distribution "pour rire" je vois pas. J'ai un (petit) pandaboard capable d'ouvrir plusieurs centaines de connexion TCP par seconde. Bon c'est vrai que Firefox a un peu tendance à bourriner en cas de reconnexion. Mais c'est plus un problème du logiciel Firefox que de Linux (genre lancer d'abord une petite dizaine de demandes de reconnexions avant de passer en mode berserk ca serait mieux). Dans la plupart des cas c'est juste que le programme devrait envoyer quelques demandes TCP avant d'estimer que là c'est bon le tuyeau est ouvert et qu'il peut se lacher (enfin sauf pulseaudio qui massacre déjà tellement la latence son avec son archi chaotique que si en plus il devait faire des tests avant d'ouvrir les trombes de connexions dont il a besoin on écouterait sa musique en morse)
Lorsqu'en plus tu as par malheur changé de timezone entretemps
Déjà évoqué plusieurs fois : il faut bosser en UTC - et un Linux bien installé travaille en UTC même si l'heure du bios est forcée sur Trinidad et Tobago. Les protocoles eux mêmes ne sont généralement pas sensibles à la référence de temps - excepté mDNS qui sur certaines implémentations par des fabricants par très malins peut avoir tendance à s'appuyer sur l'heure locale affichée pour générer des clefs de sécurité. Fort heureusement mDNS est un protocole local ce qui limite grandement la casse (enfin sauf avec Avahi qui possède une implémentation "reflector" qui permet de router un protocole non routable entre plusieurs réseaux qui ont éventuellement des timezones différentes - fou-rires assurés)
Vous me direz firewall, mais bon actuellement il faut tout droppper pour recharger des règles ce qui laisse un gap pour un attaquant.
Si tu connais déjà tes règles tu peux les ajouter et flagguer ta connexion elle même (genre écrire des règles de type - si je suis sur le réseau de José alors laisser passer tel type de connexion) Je l'ai fait quelquefois (avant de décider que définitivement IPTables c'était trop chiant à configurer pour moi) je le fais encore sous FreeBSD/OpenBSD en quelques lignes avec pf. Ca marche depuis des années sous Linux et plutôt bien (enfin sauf encore si vous avez networkd - là on ne peut plus rien pour vous et le département d'état tralala tsoin tsoin).
Donc non pas de vrai problème de mobilité avec Linux.