L'[[https://www.ubnt.com/edgemax/edgerouter-lite/|Ubiquiti Edgerouter lite]] (**ERL** pour les intimes) est un routeur semi-pro orienté SoHo, qui a la particularité d'intégrer un ASIC pour décharger sa CPU du traitement (offloader) de l'IPSec, routage IP, et du NAT (entre autres). Ceci a pour effet qu'à la différence d'autres routeurs du même segment (et prix), il permet de profiter d'une liaison internet à plein débit jusqu'à 1Gbps.

{{:informatique:hardware:erl.png?400|}}

======Performances======

Après [[https://help.ubnt.com/hc/en-us/articles/115006567467-EdgeRouter-Hardware-Offloading-Explained|activation de l'accélération matérielle]] (offloading) :
<code bash>
configure

set system offload ipv4 forwarding enable
set system offload ipv4 gre enable
set system offload ipv4 pppoe enable
set system offload ipv4 vlan enable

set system offload ipv6 forwarding enable
set system offload ipv6 pppoe enable
set system offload ipv6 vlan enable

set system offload ipsec enable

commit ; save
</code>
... j’atteins 935/195 Mbps en download/upload sur une fibre FTTH Free (NB : l'upload est évidemment bridé par mon opérateur).

======CLI en vrac======

<code bash>
# afficher la conf sous la forme de lignes de commandes
sudo show configuration commands

# voir la table de translation d'adresses
sudo show nat translations

# liste des connections ouvertes (-C affiche juste leur nombre)
sudo conntrack -L

# accéder au shell système de la Debian sous-jacente (en temps qu'admin) :
sudo -i

# faire une capture réseau
show interfaces ethernet eth0 capture 
# faire une capture avec des filtres (tcpdump)
sudo tcpdump -i eth0 -n udp and dst 10.10.10.10 and \(dst port 500 or port 4500\) -w /home/ubnt/capture.pcap

# lister la table ARP
show arp
</code>

======Problèmes======

=====SSH ne répond pas=====

J'ai le SSH de mon ERL activé sur un port custom 2222 ; je peux vérifier qu'il l'est bien dans la (webUI : System> SSH Server), cependant je n'arrive pas à m'y connecter. En sniffant le trafic sur le client, Wireshark m'indique un 3-way-handshake suivi immédiatement par un TCP-FIN envoyé par le serveur...
En désactivant/réactivant le SSH via la webUI, j'obtiens une piste dans les logs de l'ERL (webUI: Toolbox> Log Monitor) :
<code bash>
sshd[31070]: error: Bind to port 10001 on 0.0.0.0 failed: Address already in use.
sshd[31070]: fatal: Cannot bind any address.
</code>

En utilisant la CLI dans la webUI (sous Chrome, car sous mon Firefox il ne fonctionne pas) je peux confirmer que le service SSHd a bien un soucis et ne se lance pas :
<code bash>
sudo service ssh status
[FAIL] sshd is not running ... failed!
</code>

Toujours dans la CLI, en lançant un shell et en regardant ce qui tourne sur mon port 2222 je trouve un processus qui le squatte :
<code bash>
sh
sudo netstat -nlpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
#[..]
tcp        0      0 0.0.0.0:2222             0.0.0.0:*               LISTEN     1234/processus
</code>

Donc là, 2 solutions : soit le processus squatteur est inutile et on peut le désactiver pour récupérer le port ; soit il est utile et il va falloir choisir un nouveau port pour notre serveur SSHd.

======Liens======

  * [[https://help.ubnt.com/hc/en-us/categories/200321064-EdgeMAX|support UBNT]]