Intermitencias en RAP en huerta Pilmaiken #88
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: escuela-comun/abyayala#88
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Esto viene sucediendo hace más de un año, tiene downtimes importantes (uno de los servicios que lo resienten es por ej foro.pilmaiken.abyaya.la)
El server fue relocalizado a otra red y sigue sucediendo.
Mientras está desconectado de la RAP, NO está 'colgado', se puede acceder por tty, la utilización de recursos es normal (salvo por la Swap que esta medio llena)
En este estado alcancé a obser var que en comun.dot la huerta está aislada. No necesariamente esto significa que tinc está caído, aunque no pude verificar esto esta vez.
Luego bajé tinc manualmente y este archivo no se "limpió", por lo que creo que son cosas distinas. Por ende la pregunta es ¿por qué se aisla de los otros nodos?
Tendrá que ver con este otro asunto de la duplicación de MAC (¿no tenemos otro issue para eso?
Para terminar de frakear, mirando logs encontré lo que parece ser ¡un ataque de diccionario de acceso ssh, proveniente desde el proxy!
¿Es esto parte del pentesting? ¿O tenemos actores maliciosos en la red?
Luego me di cuenta que es lo esperable para un puerto SSH expuesto a la Internet
Intento debuggear más y mientras estaba caído:
@fauno el asunto de duplicación de MACs ¿tenía que ver con DHCP, no?
Me echás una mano con el gato éste?
en journalctl encontré:
Al parecer sugiere que puede trartarse de conflicto de IP o similar
Más logs
Reiniciar:
@Numerica mostrame
ip address show comunmientras está caído, tambiénip route. ese error lo he visto en algunos casos cuando el kernel no acepta el subrango de ip que le estás dando (incluyendo los que te dan algunos proveedores de vps)asi esta, cuando está caído
en cuanto a ip route, conseguí un log de cuando está up, y una imágen de cuando está down
Bueno como me puse a ver estos ip route, me cayó la teja de que habría perdido la red, y de hecho no respondía ningún
ping, no había red del todo.Tampoco deteniendo tinc, entonces me cae que algo tenía que ver el resolv.conf y noté que al reiniciar DHCPCD se restableció la conexión de red, y este archivo cambió, (en pseudo-diff)
Con esto al rato se restablece tinc también y se reconecta. Primero podés pingear a 10.13.12.1 y al rato vuelven los nodos.
Corolario
Si mal no recuerdo este taco es el parte de lo que se producía en #15 - si es que no es el problema en sí.
Que el ruteo se hace a través de la VPN, y si esta se cae se cae la net (antes había que editar resolv.conf y poner
resolver 8.8.8.8)Hipótesis
La RAP tiene intermintencias, causando ciclos de reinicio en tinc. Este ciclo podría estar roto porque al caerse tinc no limpia el archivo resolv.conf.
@fauno nos refrescás por favor la relación entre tinc y dhcpcd, (el primero le "envía comandos" según logs)
Workaround
¿Teníamos una secuencia de comandos de reinicio de la RAP para estos casos?
Logs de dhcpcd y network...
los veth son las interfaces de docker, no diría que son el problema acá.
la ip en el rango 169.254 la asigna avahi o dhcpcd automaticamente cuando no detectan respuesta de un dhcpd, es el rango de zeroconf. eso indica que no hubo respuesta o conexión con el servidor dhcp.
search comunno debería salir en el/etc/resolv.confporque el dnsmasq esta deshabilitado para eso, pero en cualquier caso tendría que dar resolución de nombres internamente. por ejemplo en sutty.comun que funciona bien, tengo esto, que sería lo mismo:la ruta cuando está up está bien, pero cuando está caído sigue ahí, debería no estar cuando tinc esta caido y cuando la interfaz
comunno tiene una ip en ese rango. creo que viene por ahi la mano.la comunicación debería ser:
abyayala(está bien queabyayalasea el unico host en/etc/tinc/comun/hosts)comundhcpcd -h NODO comunpara pedir una ip al dnsmasq enabyayaladhcpcdy se da de baja la interfazcomunaparentemente este ultimo paso no estaría sucediendo. necesito saber:
ps aux | grep dhcpcdcon tinc arriba?también
dhcpcd --version@NumericaBueno parece que lo resolvimos, el problema es que no sabemos cómo XD
Al parecer una de las redes docker de la receta de Mastodon tenía asosciado otro servicio dhcp
Esto conflictuaba con el de la RAP causando las reconexiones y la posterior pérdida de red. Me confirmás esto @fauno ?
Lo cierto es que la única acción además de ver logs fue dar de baja al paquidermo....
@Numerica hicimos dos cambios:
yo creo que ninguna de las dos cosas debería haber afectado, pero quién te dice