Le but n'est évidemment pas de protéger formellement le serveur du reste du réseau. Par contre ce genre de mécanisme ça réduit effectivement pas mal les chances d'interaction avec le reste du monde, on peut supposer que 10.1.x.x aura plus de mal à se connecter en http dessus, qu'un utilisateur standard sur celui-ci aura plus de mal à se connecter en ftp sur 10.2.x.x, etc.
Ça n'était pas rare il y a quelques années de limiter l'accès à un service via hosts.allow/hosts.deny.
C'est aussi à peu près équivalent au principe désuet de rsh où on fait confiance à l'environnement matériel et aux administrateurs des machines. La pratique de filtrer l'accès à des services via l'IP distante est aussi courante.
Ici ça serait un moyen simple et léger de restreindre l'ensemble des interactions réseau.
Ça n'est pas le seul mécanisme de protection, ça n'est pas un mécanisme formel non plus, et ça n'a aucune importance pour le problème.
D'ailleurs avec la version plus complexe du problème que je posterai plus tard, vous verrez la raison exacte pour cette configuration... Elle est valable.
[^] # Re: intéressant mais pas tout compris
Posté par Pierre Carrier . En réponse au journal Défi geek : réseau. Évalué à 1.
Ça n'était pas rare il y a quelques années de limiter l'accès à un service via hosts.allow/hosts.deny.
C'est aussi à peu près équivalent au principe désuet de rsh où on fait confiance à l'environnement matériel et aux administrateurs des machines. La pratique de filtrer l'accès à des services via l'IP distante est aussi courante.
Ici ça serait un moyen simple et léger de restreindre l'ensemble des interactions réseau.
Ça n'est pas le seul mécanisme de protection, ça n'est pas un mécanisme formel non plus, et ça n'a aucune importance pour le problème.
D'ailleurs avec la version plus complexe du problème que je posterai plus tard, vous verrez la raison exacte pour cette configuration... Elle est valable.
Je me répète : cas d'école.