Table des matières:

Bridge Firewall avec OrangePi R1 : 4 étapes
Bridge Firewall avec OrangePi R1 : 4 étapes

Vidéo: Bridge Firewall avec OrangePi R1 : 4 étapes

Vidéo: Bridge Firewall avec OrangePi R1 : 4 étapes
Vidéo: Router on Orange Pi 2024, Novembre
Anonim
Pare-feu de pont avec OrangePi R1
Pare-feu de pont avec OrangePi R1

J'ai dû acheter un autre Orange Pi:) C'est parce que mon téléphone SIP a commencé à sonner au milieu de la nuit à partir de numéros étranges et mon fournisseur VoIP a suggéré que cela était dû à des analyses de ports. Une autre raison - j'avais trop souvent entendu parler de routeurs piratés, et j'ai un routeur que je ne suis pas autorisé à administrer (Altibox/Norvège). J'étais aussi curieux de savoir ce qui se passait dans mon réseau domestique. J'ai donc décidé de mettre en place un bridge-firewall, transparent au réseau domestique TCP/IP. Je l'ai testé avec un PC, puis j'ai décidé d'acheter OPi R1 - moins de bruit et moins de consommation d'énergie. Si vous avez votre propre raison d'avoir un tel pare-feu matériel, c'est plus facile que vous ne le pensez ! N'oubliez pas d'acheter un dissipateur thermique et une bonne carte micro SD.

Étape 1: système d'exploitation et câblage

Système d'exploitation et câblage
Système d'exploitation et câblage

J'ai installé Armbian:

Comme vous l'avez peut-être remarqué, j'ai utilisé un convertisseur USB TTL pour accéder à la console série, ce qui n'était pas nécessaire, la configuration réseau par défaut suppose DHCP.

Le seul commentaire au convertisseur - dans de nombreux tutoriels, aucune connexion VCC n'est suggérée. Pour moi, cela ne fonctionnait que lorsque l'alimentation était connectée (3,3 V est la seule broche carrée sur la carte). Et il allait surchauffer s'il n'était pas connecté à l'USB avant la mise sous tension. Je suppose que R1 a un brochage compatible avec OPi Zero, j'ai du mal à trouver des schémas R1.

Après avoir démarré Armbian, changé le mot de passe root et quelques éléments de mise à jour/mise à niveau, j'ai trouvé deux interfaces ('ifconfig -a') - eth0 et enxc0742bfffc6e. Vérifiez-le car vous en aurez besoin maintenant - la chose la plus impressionnante est que pour transformer votre R1 en pont Ethernet, vous n'avez qu'à ajuster le fichier /etc/network/interfaces. J'ai été étonné qu'Armbian soit livré avec des versions préconfigurées du fichier, y compris interfaces.r1switch - cela ressemble à ce dont nous avons besoin mais cela ne fonctionne pas.

Une autre chose importante était l'identification correcte des ports Ethernet - enxc0742bfffc6e était celui près des broches série.

Avant que le R1 ne perde le contact avec Internet (OK, cela aurait pu être mieux configuré), installez simplement une chose:

sudo apt-get install iptables-persistent

Étape 2: /etc/network/interfaces

Si vous basculez votre réseau local sur eth0, vous avez besoin du fichier d'interface suivant (vous pouvez toujours revenir à la version d'origine avec sudo cp interfaces.default interfaces; reboot):

auto br0iface br0 inet manuel

bridge_ports eth0 enxc0742bfffc6e

bridge_stp off

pont_fd 0

bridge_maxwait 0

pont_maxage 0

Étape 3: Iptables

Iptables
Iptables

Après le redémarrage, votre R1 doit être transparent pour le réseau et fonctionner comme un connecteur de câble. Maintenant, rendons la vie plus difficile aux méchants - configurez les règles des pare-feu (les lignes hachées sont des commentaires; ajustez les adresses réseau à votre configuration DHCP !):

# flasher tout et fermer les portes

iptables -Fiptables -P BAISSE D'ENTRÉE

iptables -P FAIRE SUIVRE

iptables -P BAISSE DE SORTIE

# mais autorise le réseau interne à sortir

iptables -A INPUT -m physdev --physdev-is-bridged --physdev-in eth0 -s 192.168.10.0/24 -j ACCEPT

iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in eth0 -s 192.168.10.0/24 -j ACCEPT

# autorise DHCP à passer par le pont

iptables -A INPUT -i br0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT

iptables -A FORWARD -i br0 -p udp --dport 67:68 --sport 67:68 -j ACCEPTER

# tout le trafic établi doit être transféré

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED, RELATED -j ACCEPT

# juste pour le navigateur local - accès à des outils de surveillance comme darkstat

iptables -A ENTRÉE -i lo -j ACCEPTER iptables -A SORTIE -o lo -j ACCEPTER

#bloquer l'usurpation

iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in enxc0742bfffc6e -s 192.168.10.0/24 -m limit --limit 5/min -j LOG --log-level 7 --log-prefix FILTRE RESEAU

iptables -A FORWARD -m physdev --physdev-is-bridged --physdev-in enxc0742bfffc6e -s 192.168.10.0/24 -j REJECT

Étape 4: Considérations finales

Après une semaine - cela fonctionne parfaitement. La seule chose que je vais inventer (et soumettre ici) est la surveillance du réseau et l'accès via ssh. Je le répète - la modification du fichier d'interface par le contenu que j'ai joint détachera le périphérique R1 du réseau IP - seule la série fonctionnera.

6 juin 2018: le pontage n'est pas beaucoup de travail à faire mais R1 dégage beaucoup de chaleur, beaucoup trop. Un simple dissipateur de chaleur devient très chaud - étrange et je ne l'aime pas. Peut-être que ça va, peut-être que quelqu'un a une solution autre qu'un ventilateur.

18 août 2018: « armbianmonitor -m » indique 38 degrés Celsius, ce qui est bien en deçà de ma perception personnelle. J'ai ressenti un changement important (vers le bas) lorsque j'ai un peu réduit l'horloge:

echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

BTW - J'ai réussi à me connecter à mon WLAN domestique mais R1 n'a reçu aucune adresse IP via DHCP, les deos d'affectation statique ne fonctionnent pas non plus. C'était ma première tentative d'avoir une interface administrative, autre qu'une interface série. Une autre idée est d'avoir toujours une adresse IP attribuée à l'un des ports Ethernet. J'y reviendrai dans quelques mois.

Conseillé: