PEBKAC #8025

Modification d'un réseau à distance (en Angleterre) : je dois changer le sous-réseau car il a changé d'opérateur, et l'installateur n'a pas cherché plus loin que de savoir si la connexion Internet fonctionnait. Les produits avec une IP fixe étaient donc inaccessibles.

Je me connecte à une machine sur place, je change le sous-réseau de la Box, et demande au client de redémarrer le poste pour que le DHCP lui attribue une nouvelle adresse.
Et voilà : plus de connexion Internet dans tout le bâtiment… donc plus d'accès à distance à la machine.

Ah oui, changer la plage d'adresses du DHCP… PEBKAC.

PEBKAC #8025 proposé par No Name le 21/06/2013 | 14 commentaires | 👍🏽 👎🏽 +155

Epic PEBKAC...

Question idiote, mais pas tant que ça : qui va aller intervenir sur place pour réparer?

Commentaire #98092 écrit par Morrock le 21/06/2013 à 09h18 | 👍🏽 👎🏽

il mériterait bien d'y aller lui même. et à la nage! :)

Commentaire #98095 écrit par root le 21/06/2013 à 09h24 | 👍🏽 👎🏽

C'est dommage qu'il n'y ai pas de mode d'essai pour les configs réseau, comme pour les paramètres d'affichage. On passe sur la nouvelle conf pendant 1min, si on reçoit pas de confirmation on revient sur la précédente.
Ce serait quand même vachement pratique pour ce genre de contexte.

Commentaire #98115 écrit par Noraa le 21/06/2013 à 11h04 | 👍🏽 👎🏽

Dans le même style, éditer la configuration du ssh, se planter sur la config, redémarrer sshd ... et se retrouver comme un con :3

Commentaire #98121 écrit par mini le 21/06/2013 à 11h30 | 👍🏽 👎🏽

Je sais pas pourquoi mais ca sent quand meme furieusement le CTLP...
La description est un poil trop vague pour etre sur mais j'ai quand meme un serieux doute...
Bon le doute beneficie toujours au prévenu mais quand meme, j'aimerais bien un peu plus d'explications sur le rapport entre l'adressage du LAN et l'adressage du WAN (y'a peut etre des specificités chez les operateurs locaux que je ne connais pas) et cette histoire de perte du reseau dans le batiment parce qu'un poste a redemarré sur une mauvaise conf reseau...

Commentaire #98125 écrit par imbolcus le 21/06/2013 à 11h39 | 👍🏽 👎🏽

Lapin compris.

Commentaire #98157 écrit par Shirluban le 21/06/2013 à 13h09 | 👍🏽 👎🏽

Pour ce que je comprends, la modification d la plage d'IP du routeur a été faite, mais pas celle de la plage DHCP, donc les postes connectés n'ont plus d'accès (tant qu'ils n'essayent pas de négocier une nouvelle adresse ?), mais pour autant, n'étant pas très connaisseur dans le domaine, je me suis juste permis une reformulation du PEBKAC tel que je l'ai compris.

Commentaire #98176 écrit par ygnobl le 21/06/2013 à 13h49 | 👍🏽 👎🏽

Oui, c'est lui le Pebkac, mais c'est un vrai pebkac : il devait mettre a jour une config et ne l'a fait qu'en partie, du coup tout est parti en vrille.

Commentaire #98177 écrit par Matthieu le 21/06/2013 à 13h51 | 👍🏽 👎🏽

Je me suis fait exactement la même réflexion il y a peu de temps après avoir foiré une règle iptable (un autre grand classique) et je suis tombé sur ça:
http://sametmax.com/tester-une-regle-iptable/

Les commentaires proposent aussi d'autres solutions, à voir au cas par cas en fonction des besoins ;)

EDIT: un commentaire signale ceci:

man iptables-apply

iptables-apply will try to apply a new ruleset (as output by iptables-save/read by iptables-restore) to iptables, then prompt the user whether the changes are okay. If the new ruleset cut the existing connection, the user will not be able to answer affirmatively. In this case, the script rolls back to the previous ruleset after the timeout expired. The timeout can be set with -t.

Commentaire #98194 écrit par ZK456 le 21/06/2013 à 15h34 | 👍🏽 👎🏽

Nickel, il fallait bien que ca existe en effet :)
Esperons que ça soit généralisé à tous les outils du domaine !

Commentaire #98198 écrit par Noraa le 21/06/2013 à 15h51 | 👍🏽 👎🏽

Sinon, respecter les procédures de migrations ...

Commentaire #98236 écrit par A-xis le 21/06/2013 à 18h17 | 👍🏽 👎🏽

/me démarre toujours un service ssh sur un port ouvert pour lui même quand il bidouille le serveur ssh principal.

Me suis fait avoir une fois...

Commentaire #98237 écrit par A-xis le 21/06/2013 à 18h19 | 👍🏽 👎🏽

Le 's' que tu as mis à "migrations" montre bien que l'erreur est humaine, donc autant se simplifier la vie en proposant des outils permettant de rattraper ses erreurs.

Commentaire #98265 écrit par Noraa le 21/06/2013 à 20h03 | 👍🏽 👎🏽

Explication pour être plus clair,

Le client avais son réseau configurer pour la plage 192.168.64.X (DHCP + IP fixe)
Le nouvel opérateur arrive met son routeur et laisse tout par défaut a savoir 192.168.1.X
=> Donc perte de l'accès internet sur les produits en IP fixe
Je change l'IP du routeur pour 192.168.64.X mais oubli le DHCP donc maintenant c'est l'inverse seul les produits en IP fixe ont accès a internet et le reste est bloquer dans son coin.

Donc au final des équipements réseau en IP fixe avais internet mais tout les ordinateur en DHCP était toujours en 192.168.1.X donc couper d'internet

@Morrock On a du dépêcher un tech réseau sur anglais pour faire cette motif qui a plus coûté en transport qu'en prestation..

Commentaire #98685 écrit par No Name le 24/06/2013 à 11h27 | 👍🏽 👎🏽