Bonjour,
Ayant énormément souffert pendant 6 ans en étant obligé d'administrer
des serveurs Windows en entreprise (mises à jours qui rendent le
fonctionnement aléatoire, virus, insomnies, dépression, calvitie...), je
cherche maintenant lors de mon temps libre à sélectionner et à tester
des solutions alternatives libres fiables qui marchent sous GNU/Linux.
Avec un membre du GRAOULUG (Lug de Metz), nous avons testé l'intégration
d'un poste Linux Mint dans un domaine Active Directory :
http://www.numopen.fr/Integrer_un_ordinateur_Linux_Mint_MATE_dans_un_domain…
C'est très certainement améliorable mais c'est un début. Lors de la
dernière réunion du GRAOULUG hier, nous étions plusieurs personnes
intéressées pour tester l'installation et le paramétrage d'un domaine
sous GNU/Linux. Nous avons proposé de créer un groupe d'échange avec
toutes les personnes intéressées par ce sujet. Si vous souhaitez
participer, merci de me contacter.
Les activités possibles seraient par exemple :
- mettre en place, fournir ou simplement choisir des outils de
communication déjà existants pour échanger entre nous et pour la
communication externe
- répertorier les documentations intéressantes, récentes, mises à jour
régulièrement (manuels, témoignages, sites persos, listes et forums...).
- répertorier et sélectionner ce qui marche le mieux actuellement : base
Debian + SAMBA4 + tout le reste installé à la main ou offre complète
style FreeIPA, Active Directory Server de Synology, Samba Active
Directory de Tranquil IT System, SambaÉdu, SAMBA+, Seth du projet EOLE,
Zential...
- faire tous les tests qu'on veut, documenter (très important, c'est
l'objectif final en fait) ce qui marche et ce qui ne marche pas.
- autres...
Si vous pouviez aussi relayer ce messages sur les réseaux sociaux, sur
les listes, ce serait sympa.
--
Installer facilement GNU/Linux : http://numopen.fr
.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon GNU/Linux
(| |)
/ \_ _/ \
\___)=(___/
Let's say the firewall outside interface is 192.168.1.254/24. The
general Internet access (vDSL modem) is 192.168.1.1/24, connected to the
firewall by Ethernet. It NATs all outgoing IP traffic to the Internet by
replacing the source IP address by its own public IP address
(masquerading) to make it routable on the World Wild Internet.
A new secondary Internet access is added. It is implemented by a Meraki,
operated by POST. I have NO ACCESS to its configuration, not even the
pppoe credentials, so no ways to circumvent it.
The Meraki LAN interface is, let's say, 192.168.1.100/24. It has a fixed
public IPv4 WAN address. All incoming traffic (limited to IPv4, with a
limited MTU and only ICMP, UDP or TCP because of POST limitations) is
forwarded to the firewall outside IP address, 192.168.1.254/24, by POST
configuration.
This way, the general traffic works as usually and previously: through
the general Internet access, the default gateway, the vDSL modem. There
is so in the firewall a "default route" with 192.168.1.1 as default gateway.
Some selected traffic can be routed to the POST Internet access,
depending on its destination IP address or because of flagged traffic
(iproute with marks and multiples routing tables to select the
appropriate gateway).
As example, all the traffic to youporn (216.18.168.116) could be routed
through the POST Internet access by adding a static route on the firewall:
# route add -host 216.18.168.116 gw 192.168.1.100
This traffic takes so the POST Internet access to reach its destination,
and is NATed by the Meraki (source IP address NAT), so the return
traffic reaches back the POST Internet access, and is reverse-NATed back
to the firewall...
The problem is to try to _use the POST Internet access for INCOMING
traffic_.
If a connection attempt comes from the Internet (let's say 1.1.1.1)
through this POST Internet access, the IP packet is forwarded to the
firewall ("exposed host") by the Meraki, because of POST configuration,
and it is what is expected. But as this packet has still 1.1.1.1 as
source IP address, the answer to this request is routed back to the
Internet by the general Internet access, so will be NATed (masqueraded)
from a different public IP address.
The host 1.1.1.1 will then receive answer to it's connection attempt
from a completely different IP address, and so will not link it to the
request, so it won't work.
The solution would be to masquerade the source IP address of the
incoming traffic crossing the Meraki, so that the firewall would see it
as coming from the Meraki internal IP address, in this example
192.168.1.100/24.
The firewall will then answer the request apparently coming from
192.168.1.100, and the Meraki should reverse-NAT it back to it's actual
destination, in this example 1.1.1.1. The connection will establish.
For sure, I know that in this case, the firewall will not be able to
filter incoming traffic based on it's source IP address, but it's just
about making it possible, not (yet) clever or appropriate.
So I ask POST technical service to set-up this internal NAT, and they
answer that it's NOT SUPPORTED by the Meraki. I can't believe Cisco has
became so bad that they are not able to do this simple masquerading,
especially as I suspect they use Linux as underlying technology...
So I looked at Meraki documentation, but I didn't found anything else
than a very basic web-based configuration interface manual. That's why I
ask if:
* Somebody knows Meraki
* Is Meraki based on Linux kernel ?
* Is there a way to access the Meraki CLI ?
* Is there a way to configure this very basic traffic masquerading rule ?
So that I could find a solution (at least limited so far) and learn POST
help-desk again something they didn't know...
Note: changing the default route IS NOT an acceptable solution, as
changing the default Internet access would have lots of other
consequences, due to historical reasons.
The incoming traffic through the POST Internet access comes potentially
from /any/ public IPv4 routable address. It should be answered by the
two Internet accesses.
Actually, the real situation is more complex: the firewall is exposed to
incoming traffic from already three Internet accesses, provided by
various ISPs and technologies. And it works, as I have control over
those Internet accesses.
The problem occurs just because of this fourth "Internet access" by
POST, which is out of my control and apparently unable to provide this
basic feature: masquerading the incoming traffic.
By the way, I'm not even sure this "Internet access service" can be
qualified of "Internet access" as anybody knows (or should know) that
what is common on the Internet is... the IP protocol. However, this
"Internet access" service is strictly limited to IPv4, and to only the
TCP, UDP and ICMP protocols. This is so a very limited Internet access,
somehow as you might have received from some hotels in old times: a
"Internet access" that was limited to web browsing, and blocked any
"unknown" service, such as SSH, telnet, IMAP, and so on. This also
happened in the very old days (about 15 years ago) when some ISPs
blocked SIP traffic or added intentionally jitter to the VoIP audio
streams...
Those limitations have been ruled as illegal already, but here in
Luxembourg, there is a delinquent company called POST that still apply
such restrictions, apparently...
Practically, those restrictions prevents customers to access to:
* IPSec VPNs, as some implementations requires ESP and AH protocols
(not TCP or UDP)
* GRE
* IPinIP
* PIM, IGMP (for multicast)
* various routing protocols
* IPv6
* RDP
* and so on...
which are _part of the Internet protocols_, even if unknown by POST
commercial management, apparently.
I notice that some other ISPs (LOL, MixVoIP, ...) do provide genuine
Internet accesses, with full 1500 MTU and all the services above IP, as
expected...
Any help would be appreciated.
Le 08/04/2019 à 12:17, Gökdağ Göktepe a écrit :
> I am trying to figure out your problem but French is a bit complicated
> for me. As an instance I think it has sth to do with administrative
> distance . But I don’t know if you have static routes defined for your
> secondary internet access and how
>
> Gökdağ
>
> On 8 Apr 2019, at 11:56, Brent Frère <Brent.Frere(a)abilit.eu
> <mailto:Brent.Frere@abilit.eu>> wrote:
>
>> Not yet.
>>
>> Le 08/04/2019 à 11:17, Gökdağ Göktepe a écrit :
>>> Hi Brent did you find any solution?
>>>
>>> Gökdağ
Qqun sait-il s'il existe une ligne de commande pour configurer un Cisco
Meraki ?
Qqun a-t-il une expérience avec ce genre de truc ?
On dirait (vu le log) que c'est un noyau Linux... Une confirmation ?
Je cherche, en fait, à faire une NAT (masquerade) dans le sens de
l'entrée (WAN vers LAN) pour permettre au firewall de savoir par où
router le trafic en sortie.
Un dessin valant mieux qu'un long discours:
Le firewall a pour default gateway le chemin principal, mais peut
recevoir aussi du trafic provenant de l'Internet via une adresse IP
publique et fixe, via un accès Internet secondaire.
Le problème, c'est qu'ignorant que ce trafic lui vient via l'accès
secondaire, il répond naturellement via l'accès principal, et donc le
trafic est asymétrique et ne fonctionne pas. J'aurais voulu donc que cet
accès secondaire (implémenté par un Meraki de POST) natte (masquerade)
le trafic comme provenant de l'Internet via cet accès secondaire comme
émanant de l'adresse LAN (en jaune) de sorte que le firewall puisse
router le trafic en retour via l'accès secondaire, puisqu'il répond
alors à l'adresse IP qu'il voit, celle en jaune.
Post me dit que cette fonctionnalité (NAT vers l'intérieur) n'est pas
supportée par le Meraki, ce qui m'étonne.
Quelqu'un a-t-il une idée ?
je voudrais bien me désinscrire de votre newsletter.
j'ai déjà essayé plusieurs fois via votre site web, sans succès.
par email, sans succès !
merci de me désinscrire immédiatement
Le 05/04/2019 à 15:26, lilux-info-request(a)lilux.lu a écrit :
> Send Lilux-info mailing list submissions to
> lilux-info(a)lilux.lu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.lilux.lu/mailman/listinfo/lilux-info
> or, via email, send a message with subject or body 'help' to
> lilux-info-request(a)lilux.lu
>
> You can reach the person managing the list at
> lilux-info-owner(a)lilux.lu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Lilux-info digest..."
>
>
> Today's Topics:
>
> 1. Cisco Meraki (Brent Frère)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Apr 2019 15:26:05 +0200
> From: Brent Frère <Brent.Frere(a)AbilIT.eu>
> To: lilux-info(a)lilux.lu
> Subject: [Lilux-info] Cisco Meraki
> Message-ID: <83a9bc78-cfb4-0496-c5e2-7c3ab57fd3bb(a)AbilIT.eu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Qqun sait-il s'il existe une ligne de commande pour configurer un Cisco
> Meraki ?
> Qqun a-t-il une expérience avec ce genre de truc ?
>
> On dirait (vu le log) que c'est un noyau Linux... Une confirmation ?
>
> Je cherche, en fait, à faire une NAT (masquerade) dans le sens de
> l'entrée (WAN vers LAN) pour permettre au firewall de savoir par où
> router le trafic en sortie.
>
> Un dessin valant mieux qu'un long discours:
>
> Le firewall a pour default gateway le chemin principal, mais peut
> recevoir aussi du trafic provenant de l'Internet via une adresse IP
> publique et fixe, via un accès Internet secondaire.
>
> Le problème, c'est qu'ignorant que ce trafic lui vient via l'accès
> secondaire, il répond naturellement via l'accès principal, et donc le
> trafic est asymétrique et ne fonctionne pas. J'aurais voulu donc que cet
> accès secondaire (implémenté par un Meraki de POST) natte (masquerade)
> le trafic comme provenant de l'Internet via cet accès secondaire comme
> émanant de l'adresse LAN (en jaune) de sorte que le firewall puisse
> router le trafic en retour via l'accès secondaire, puisqu'il répond
> alors à l'adresse IP qu'il voit, celle en jaune.
>
> Post me dit que cette fonctionnalité (NAT vers l'intérieur) n'est pas
> supportée par le Meraki, ce qui m'étonne.
>
> Quelqu'un a-t-il une idée ?
>
>
On sait comment sont stockés les fichiers des backups "rsnapshot" (hard
links, nombreuses références vers de mêmes données sur les disques, ...)
Ex:
/monthly.0/serveur1/répertoire1/fichier1
/monthly.0/serveur1/répertoire1/fichier2
/monthly.0/serveur1/répertoire2/fichier1
/monthly.0/serveur1/répertoire2/fichier2
/monthly.0/serveur2/répertoire1/fichier1
/monthly.0/serveur2/répertoire1/fichier2
/monthly.0/serveur2/répertoire2/fichier1
/monthly.0/serveur2/répertoire2/fichier2
/monthly.1/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire1/fichier2
/monthly.1/serveur1/répertoire2/fichier1
/monthly.1/serveur1/répertoire2/fichier2
/monthly.1/serveur2/répertoire1/fichier1
/monthly.1/serveur2/répertoire1/fichier2
/monthly.1/serveur2/répertoire2/fichier1
/monthly.1/serveur2/répertoire2/fichier2
[...]
La manière dont fonctionne rsnapshot fait que des mêmes fichiers.
contenus dans des répertoires identiques (mêmes noms, même paths), sur
des serveurs identiques mais dans des backups différents, n'occupent
qu'une fois l'espace nécessaire (une seule "copie physique" des données
sur les disques).
De ce fait, si on change le nom d'un fichier, le backup suivant _refait
une copie des données_ et donc on occupe le double d'espace disque que
nécessaire.
Pire: si on renomme un répertoire, tous les contenus de ce répertoire
(et de l'arborescence située en dessous) sont recopiés, nécessitant
potentiellement un espace-disque important, totalement inutile puisque
les contenus restent les mêmes.
Idem si on change le nom d'un serveur (majuscule/minuscule ou numéro de
version, par exemple).
L'outil rdfind détecte ces cas, et remplace des copies identiques de
contenus par des "hard links", c'est-à-dire économise de
l'espace-disque, sans aucun autre effet non souhaité (en cas de
renommage, de modification par exemple).
Après des tests de grande taille, il apparaît que les backups, avant et
après le passage de rdfind, sont bien identiques. Mais on peut faire
encore mieux.
Sur divers serveurs, on trouve naturellement de nombreux fichiers
identiques (ex: librairies, fichiers "packages", ...), ce que rsnapshot
ne remarque pas, et donc fait des copies multiples, alors que le contenu
est le même.
Il y a aussi le cas des copies multiples de mêmes documents sur un
serveur de fichier, par exemple. Ainsi, une même vidéo peut être
conservée des dizaines de fois dans un même serveur, chaque utilisateur
en conservant une copie dans son espace personnel.
La commande rdfind peut tenir en compte ces situations, à condition
d'utiliser l'option "-removeidentinode false". En effet, par défaut, il
ne le fait pas. Exemple:
Imaginons que les fichiers "fichier1" sont tous identiques.
/monthly.0/serveur1/répertoire1/fichier1
/monthly.0/serveur1/répertoire2/fichier1
/monthly.1/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire2/fichier1
Avec un coup de rdfind "classique, les deux copies seront remplacées par
_deux___ copies. En effet,
/monthly.0/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire1/fichier1
sont déjà des "hard links" vers un même contenu, et
*/monthly.0/serveur1/répertoire2/fichier1*
/monthly.1/serveur1/répertoire2/fichier1
sont des "hard links" vers _une autre_ copie. On a donc bien _deux_
copies physiques _avant_ le passage de rdfind.
Après, la situation est:
/monthly.0/serveur1/répertoire1/fichier1
/monthly.1/serveur1/répertoire1/fichier1
*/monthly.0/serveur1/répertoire2/fichier1*
qui référencent tous une même copie physique, et
/monthly.1/serveur1/répertoire2/fichier1
qui référence une _autre_ copie physique. En effet, par défaut, rdfind
ne traite _qu'une seule fois_ des références multiples d'un même contenu
(hard links vers un même contenu). rdfind considère donc _deux copies_,
et ne remplace donc qu'une seule fois une entrée dans un répertoire (ici
/monthly.0/serveur1/répertoire2/fichier1) par un hardlink vers l'autre
copie.
Du fait que l'autre référence n'est pas traitée, il subsiste une
référence vers la seconde copie (ici
/monthly.1/serveur1/répertoire2/fichier) et donc _on ne gagne aucune
place dans le stockage_. On est passé de deux références vers la copie A
plus deux références vers la copie B à trois références vers la copie A
et une référence vers la copie B, mais les deux copies subsistent.
Si on repasse une couche de rdfind. on va effectivement "fusionner" la
dernière copie aux autres, et libérer de l'espace disque. Mais dans le
cas réel de backups via rsnapshot, on risque d'avoir des milliers de
fichiers qui sont identiques sur divers serveurs (modules du kernel,
librairies, ...) et donc il faudrait exécuter rdfind autant de fois que
nécessaire jusqu'à ce que plus rien ne change.
Comme l'économie de place ne survient, en pratique, qu'au moment de la
disparition de la dernière référence au contenu redondant, il est
nécessaire de procéder ainsi.
Sauf que rdfind dispose d'une option "-removeidentinode", qui évite à
cette commande de ne pas s'intéresser aux copies multiples d'un même
contenu (même inode = hardlinks). Après tests, je peux affirmer que la
commande rdfind, avec l'option "-removeidentinode" sur false, a le
comportement attendu: il remplace _en une seule passe_ *toutes les
copies d'un même contenu* !
Il suffit donc de faire exécuter la commande
> rdfind -removeidentinode false -makehardlinks true -makeresultsfile
> true -outputname /var/log/rdfind_result.log /Backup/monthly.0
> /Backup/monthly.1
après exécution d'un "rsnapshot" monthly...
Bon à savoir.
