"Exceeded MaxStartups" : erreur du monitoring sur des services ouverts sur le monde en SSH… jamais vu.
En fait il s'agit d'une limite pour éviter les DoS, ajoutée dans OpenSSH en… 2000, MaxStartups. En gros un mécanisme pour limiter puis interdire les nouvelles connexions lorsqu'il y en a trop d'ouvertes mais pas abouties simultanément.
J'ai passé le minimum de déclenchement de 10 à 15. À voir si ça suffit.
Et oui c'est sur un port différent de 22 (trolls proof). Et oui il y a déjà fail2ban, mais il faut croire qu'il a pas le temps de réagir.

Attention : si on modifie la commande forcée liée à la clef SSH (command=) utilisée pour la connexion ControlMaster, il faut relancer la connexion, le fichier n'est pas relu.

Ne pas oublier que pour un service systemd, stdin est /dev/null… sinon on peut passer du temps de debug bizarre au moment où on veut passer un script en service systemd… ici socat, qui y est très sensible puisque c'est son seul taff (de gérer des flux).

Je voulais pouvoir fournir un flux d'informations d'un script shell (bash) à quiconque voudrait le recevoir et jouer avec.
Forcément, on pense à un fifo en premier, mais les write sont bloquants. A priori pas simple le O_NONBLOCK en bash.
Ensuite on pense à des socket UNIX, sauf que c'est celui qui écoute qui la crée, et on ne peut pas écouter à plusieurs.
Ce thread fait un peu le tour. Une proposition parle de détourner UDP pour ça, car en mode datagram les paquets sont envoyés sans connexion, donc peuvent être perdus.
Avec socat c'est très facile (udp-datagram / udp-recv). Et l'envoi n'est effectivement pas bloquant. Par contre si on écoute à plusieurs sur le port, en mode reuseport, on n'a pas de duplication mais un balancing. La duplication s'effectue en mode broadcast (possible sur 127.255.255.255 par exemple).

socat udp-recv:3333,reuseport -
socat - udp-datagram:127.255.255.255:3333,broadcast <<< coucou

Ho sympa ça, l'implémentation OpenSSH permet de créer une connexion persistante "ControlMaster" qu'on pourra utiliser par la suite pour aller taper régulièrement sur un serveur sans à chaque fois refaire la connexion à zéro (et donc spammer les logs, manger la latence etc.).

Lancée via autossh, on a donc une sorte de connexion permanente et qui doit être résiliente en cas de coupure (volontaire ou panne).

Donc WDS c'est le nom d'une "techno" pas standardisée, que beaucoup de fabriquants d'antennes (wifi) implémente à sa sauce mais donc pas compatible entre eux. J'ajouterai que si t'es un gros malin comme moi et l'active d'un côté de ton pont wifi mais pas de l'autre, bah ça pas marche non plus :)

En gros ils se débrouillent pour rendre les antennes transparentes sur le LAN, en ne modifiant pas l'adresse MAC des paquets alors que les antennes sont en réalité en intermédiaire. Comme un switch quoi.

J'ai testé avec et sans, et effectivement avec j'ai bien la MAC du client derrière le pont d'antennes qui remonte jusqu'au bout. Pourquoi pas, c'est toujours ça de charge en moins et ça aide au débug.

Debug résal des deux derniers jours, on a (re)vu plein de notions, et appris quelques commandes/sysctl sympas !

Depuis le temps que je bidouille du /e/n/i je n'avais jamais eu à mettre plusieurs IP au même bloc iface… en fait c'est simple (apparemment depuis iproute2), il suffit de mettre 2 blocs iface. Même que ça marche (sous Buster) !

Pour faire un gros transfert (plusieurs centaines de To), j'ai tenté d'après cette réponse le coup de tar + mbuffer. Avec de gros buffers côté mbuffer, c'est vraiment pas mal. Et mbuffer gère lui-même la partie réseau (avec -I et -O). On pourrait peut-être imaginer compresser en plus ou éviter les header de tar mais c'est déjà pas si mal je trouve.
Sur réseau 10 Gbps, on arrive à monter à du 250 Mo/s avec le vent dans le dos : c'est probablement un des systèmes de fichiers distribué qui traine, le transfert tourne alors que tout est en prod, etc. En tous cas c'est beaucoup plus rapide qu'un simple rsync (encore heureux). Mais forcément on ne peut pas reprendre s'il y a un crash…

Notes de mon approche pour passer sur une fibre Orange du vieux PPPoE à DHCP. Le principal problème étant que dans ma zone il est nécessaire de taguer les paquets DHCP avec la bonne priorité VLAN… j'ai donc patché busybox et odhcpc6.

À noter qu'au passage, j'ai de l'IPv6 native, un débit qui passe de 100/100 à 400/400 et je ne remonte plus forcément à Paris (donc meilleur routage vers Francfort par exemple et géoloc au bon endroit). Et aussi, plus de changement d'IP systématique toutes les semaines, même si l'IP risque de changer quand même en cas de coupure prolongée.

… en tous cas sur un Tplink Archer C7 v4, le hardware offloading fonctione avec OpenWRT 19.07 ! Je suis passé de environ 350 mbps avec iperf3 à 750 mbps (donc proche de la limite à 800 de mon abonnement fibre). C'est pas mal de savoir qu'un firmware libre arrive à ces débits sur du NAT sur un routeur grand public.

À savoir que l'offload se fait à coup de règles iptables, se configure donc au niveau du firewall (et si on utilise l'interface luci, ce sont des cases à cocher : Système -> Firewall -> software offload et hardware offload).

Exemple :
FLOWOFFLOAD all -- anywhere anywhere / !fw3: Traffic offloading / ctstate RELATED,ESTABLISHED FLOWOFFLOAD hw

J'ai voulu tester du let's encrypt (oui…) sur une VM Alpine. Apparemment il y a enfin un setup simple, qui fait ce qu'on veut et qui juste marche. Mais je n'ai pas encore pu tester le renouvellement auto évidemment.
Avec les paquets, on peut installer acme-client-plus et acme-client. Le dernier est le client ACME d'OpenBSD, écrit en C et avec pas mal de fontionnalités (mais pas les wildcard si j'ai bien compris). Le premier est un script shell et les quelques fichiers de conf pour qu'il renouvelle au besoin.
Plus rien à copier, mettre en place, installer, il suffit de faire un "acme-client-plus issue" et hop on a son certificat (une fois qu'on a corrigé nos erreurs de DNS/routage/config serveur web/…). Un peu comme le script que j'avais mis en place il y a longtemps, à la main. Là c'est pareil mais en tout prêt.
À voir au renouvellement… !

Apparemment Alpine, bien qu'utilisant /etc/networg/interfaces à la Debian, n'a pas les petits sugar genre autoconf, dad-attempts, accept_ra etc.
Dans leur doc ils disent de désactiver la prise en compte des RA d'IPv6 avec un pre-up (soit avec un echo, soit avec sysctl). Seulement chez moi ça ne suffit pas, la route par defaut est déjà mise en place avant que ifup ne se bouge, donc on a une erreur "file exists" (mais qui ne gène pas). Par contre, la default est valide seulement le temps d'expiration du RA qui a été pris en compte. Donc au bout d'un moment la default disparait \o/ pour le voir, champ "expires" :
default via fe80::xxxx dev eth0 proto ra metric 1024 expires 1778sec hoplimit 64 pref medium
J'ai simplement créé un fichier sysctl :
$ cat /etc/sysctl.d/01-noslaac.conf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.dad_transmits = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.eth0.accept_ra = 0
net.ipv6.conf.eth0.dad_transmits = 0

et là plus de problème. Oui je bourrine, mais on sait jamais si le nom de l'interface venait à changer par exemple #traumatisé. :)

Ma syncho mail était cassée depuis quelques temps par perte de connectivité entre mes deux réplicats dovecot (en IPv6, pas d'accès tunnel HE chez Cogent).
Pour contourner cela, je me suis demandé s'il n'y avait pas moyen de faire du routage dans un tunnel SSH. Et la réponse est oui, c'est même facile : ssh -w 0:0 (en root des deux côtés) va créer une paire de tun0 qu'il suffira de configurer !
ip link set tun0 up
ip route add … dev tun0
… le forwarding, etc.

En lisant la page liée, j'ai donc juste eu à créer une paire de clefs SSH, faire la config (sshd_config without-password et PermitTunnel) et c'est tombé en marche rapidement :)

Fichiers sysfs faciles à accéder pour voir les compteurs des interfaces réseau sans passer par une commande ou parser des sorties plus ou moins obsolètes comme ifconfig. Exemple pour le rx :
/sys/class/net//statistics/rx_bytes
/sys/class/net//statistics/rx_packets

Pour ARN, pour travailler sur un incident on aurait eu besoin d'une sorte de smokeping (ping en continu avec graph pour voir quand il y a des problèmes (latence, pertes, …)). J'ai cherché rapidement et à part "smokeping" qui a un mode daemon et visualisation web, le reste avait l'air proprio/winwin/…
Je suis tombé par hasard sur la page liée ici, où, simplement, ils font ça avec… ping et gnuplot.

J'ai donc bidouillé à partir de là, et au final ça donne :

ping4 -i 10 addresse-à-tester -D -n | grep --line-buffered icmp_seq | awk -F [=\ ] -W interactive {'print $1, " ", $(NF-1); fflush()'} | stdbuf -o0 tr -d '[]' > /dev/shm/pings4

Le plus difficile est à chaque commande pour être sûr de ne pas bufferiser, ce qui permet de lire le fichier de sortie immédiatement, sans arrêter la commande ou autre. Pas de soucis de faire des petites écritures puisqu'on envoie dans un ramdisk.
On a donc des paires "timestamp RTT"

Pour grapher cela, on peut utiliser :

gnuplot -e 'set term png size 1280,1024; set output "ping.png"; set xlabel "Time (UTC)"; set ylabel "RTT in milliseconds"; set xtics rotate; set xdata time; set timefmt "%s"; set format x "%b %d %H:%M"; clamp(a) = (a < 42) ? a : 42; plot "pings4" using 1:(clamp($2)) notitle'

Ici le plus sioux c'est d'une part la gestion du temps (timestamp vers "pretty"), d'autre part la limite (min ou clamp) pour éviter d'avoir un graph tassé/pollué par les ping vraiment trop hauts. Ici tout ce qui est plus grand que 42 ms est affiché à 42.

Ce qui reste difficile, c'est la détection de pertes. On ne les voit pas vraiment, surtout quand le graph commence à être large. En général en cas de problème on le remarquera autrement (nous ici, session BGP qui tombent). Après on peut aller fouiller en mode interactif (sans utiliser la sortie PNG de gnuplot). Et là on voit rapidement quand il y a un "trou" dans une certaine zone. En général ça correspond aussi à des moments où il y a eu un lot de ping à plus de 42 ms de RTT.

Si des gens veulent utiliser ça, en tous cas c'est relativement sans prise de tête et sans installation ou autre !

Pour renvoyer des flux TCP ailleurs (bounce), on peut utiliser socat facilement (pas besoin de root pour les ports > 1024 ni d'iptables).
Exemple :
socat TCP-LISTEN:4242,fork TCP:machine-destination:3032
C'est une sorte de NAT sur un seul port, et qui évite de devoir monter une session de tunnel SSH.

Dans une trame ethernet, le tag 802.1Q (aussi connu comme « dot1q ») se glisse entre la MAC source et l'ethertype.
Les 2 premiers octets (qui seraient ethertype sinon) sont une sorte de "magic number" pour dire « hééé c'est le numéro de vlan qui va suivre, pas le payload ». Ensuite -- et c'est ce que j'ai découvert aujourd'hui -- il y a 3 octet de classe de service, un niveau de priorité. Et c'est celui-ci que je cherchais (après m'être fourvoyé dans du DSCP, qui lui est dans la trame IP).
Apparemment c'est utilisé, et il est même précisé ici qu'on peut faire du 802.1Q uniquement pour ça (en mettant un numéro de VLAN bidon, 0).

NB : à la question « est-ce que ça fait fragmenter de mettre un tag 802.1Q » il semblerait que la réponse soit non, en fait ça rallonge juste la trame mais le payload reste aux même limites, ce qui est pratique (ça compte même pour diminuer le minimum du payload, logique).

J'ai voulu me connecter à IRC en IPv6 via un tunnel HE (https://tunnelbroker.net/). Hé bah non. Filtré.
Sur le forum ci-lié on lit :
"I realized that I have to go through all the certifications to enable IRC ports."
En testant au pif avec telnet on trouve qu'on n'a pas de connexion refusée sur 6660-6670 inclus et 6697 mais bien aucune réponse, donc du drop. Nmap confirme :
$ nmap -6 -sT -p 6650-6750 vp.michalon.eu
Starting Nmap 6.47 ( http://nmap.org ) at 2016-03-06 20:55 CET
Nmap scan report for vp.michalon.eu (2a00:5881:8110::1)
Host is up (0.064s latency).
Not shown: 89 closed ports
PORT STATE SERVICE
6660/tcp filtered unknown
6661/tcp filtered unknown
6662/tcp filtered radmind
6663/tcp filtered unknown
6664/tcp filtered unknown
6665/tcp filtered irc
6666/tcp filtered irc
6667/tcp filtered irc
6668/tcp filtered irc
6669/tcp filtered irc
6670/tcp filtered irc
6697/tcp filtered unknown

Un nmap similaire mais sur tous les ports (1-65535) montre "31 filtered ports" (j'ai pas eu le détail du coup).

Pour vérifier que c'est pas sur le retour le filtrage mais bien à l'aller, j'ai limité le nmap sur 6695-6699
nmap -6 -PN -sT -p 6695-6699 -r vp.michalon.eu
et tcpdump les TCP SYN de l'autre côté (lignes de sortie raccourcies ; merci http://www.packetlevel.ch/html/tcpdumpf.html pour le filter).
tcpdump -i eth0 -n "ip6 and (ip6[6] == 0x06) and (ip6[53] == 0x02)"

2a00:5881:8110::1.6695: Flags [S]
2a00:5881:8110::1.6696: Flags [S]
2a00:5881:8110::1.6698: Flags [S]
2a00:5881:8110::1.6699: Flags [S]

lala.

Création d'un réseau guest sur mon Netgear WNR3500L v2 flashé avec TomatoUSB, tout fonctionne (coupe deux fois les connexions, au VLAN car reboot comme prévu mais aussi au moment de créer le br1).
Je n'ai pas eu à jouer avec iptables comme demandé : ça fonctionne comme je veux de base (sortir vers l'extérieur autorisé, passer entre les réseaux internes bloqué). Ça se vérifie, les compteurs iptables augmentent bien un par seconde avec des ping de test (guest => principal, principal => guest, guest => dehors) :
355 29820 DROP all -- br1 br0 anywhere anywhere
=> le 355 augmente
46 3864 DROP all -- br0 br1 anywhere anywhere
=> le 46 augmente
40 3360 ACCEPT all -- br1 any anywhere anywhere
=> le 40 augmente

Voila voila, je suis prêt pour quand des gens viendront avec un win10 et que j'oserai pas dire que non mais je donne pas mon mot de passe à 'crosoft :P
Là j'en donnerai un autre…