| Commit message (Collapse) | Author | Age | Files |
|---|
| |
|
|
|
| |
Using client-side data signing/encryption and wrapping inter-host
communication into stunnel.
|
| | |
|
| |
|
|
|
|
| |
(Unless a new instance is created, or the master.cf change is modified.)
Changing some variables, such as inet_protocols, require a full restart,
but most of the time it's overkill.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead, generate a server certificate for each host (on the machine
itself). Then fetch all these certs locally, and copy them over to each
IPSec peer. That requires more certs to be stored on each machines (n
vs 2), but it can be done automatically, and is easier to deploy.
Note: When adding a new machine to the inventory, one needs to run the
playbook on that machine (to generate the cert and fetch it locally)
first, then on all other machines.
|
| |
|
|
|
|
| |
We use a "master" NTP server, which synchronizes against stratum 1
servers (hence is a stratum 2 itself); all other clients synchronize to
this master server through IPSec.
|
| | |
|
| | |
|
| |
|
|
| |
We use a dedicated instance for each role: MDA, MTA out, MX, etc.
|
| |
|
|
| |
This is pointless since the service will be restarted anyway.
|
| |
|
|
|
|
|
| |
At the each IPSec end-point the traffic is DNAT'ed to / MASQUERADE'd
from our dedicated IP after ESP decapsulation. Also, some IP tables
ensure that alien (not coming from / going to the tunnel end-point) is
dropped.
|
| |
|
|
|
| |
These rules are automatically included by third-party servers such as
strongSwan or fail2ban.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
