If you have a VPS or a Dedicated Server with /64 IPv6 subnet and want to use it on your device at home to make it accessible from the internet directly, you can make a tunnel through the Yggdrasil network.

Yggdrasil network is already end to end encrypted, so we can use vxlan over it for this purpose.

On the server with IPv6 subnet we have to install bridge-utils and configure bridge to our external interface:
apt install bridge-utils
brctl addbr br0
brctl addif br0 eth0

then we need to add a vxlan to the server and connect it to the bridge also:
ip link add vxlan0 type vxlan id 42 local $YGGDRASIL_SERVER_IP remote $YGGDRASIL_HOME_IP dstport 4789

where $YGGDRASIL_SERVER_IP and $YGGDRASIL_HOME_IP – your server’s IP in the Yggdrasil network, and home device’s IP in the Yggdrasil network accordingly.

Making the interfaces up:
ip link set up br0
ip link set up vxlan0

Now we are going to the home device:
ip link add vxlan0 type vxlan id 42 local $YGGDRASIL_HOME_IP remote $YGGDRASIL_SERVER_IP dstport 4789
ip link set up vxlan0
ip a a $your_real_ip_from_the_servers_subnet/64 dev vxlan0
route -6 add default gw $your_servers_ipv6_gateway

Thats it.

How to install and configura Yggdrasil network read on the developer’s website. Maybe I’ll write an article later.

I used Ubuntu 20.04 on all the servers. This manual is also suitable for baremetal setup.
In this manual we will use 7 VMs in the same 10.0.0.0/24 network:

  • Kubeapi Load Balancer with HAProxy (10.0.0.90)
  • 3x master nodes (10.0.0.71-10.0.0.73)
  • 3x worker nodes (10.0.0.81-83)

The best way to create 7x VM quickly is to prepare one and clone it (or it’s disk image) before the cluster setup. Once the OS (Ubuntu/Debian) installed, perform the package update and upgrade:

sudo apt update && sudo apt upgrade

If you setting up a VM and clonning it, it needs to change the machine ID and host SSH keys:

rm -f /etc/machine-id
dbus-uuidgen --ensure=/etc/machine-id
rm /var/lib/dbus/machine-id
dbus-uuidgen --ensure
/bin/rm -v /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
systemctl restart ssh
reboot

Installing CA and creating certificates

We will use CFSSL tool from Cloudflare
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
chmod +x cfssl*
sudo mv cfssl_linux-amd64 /usr/local/bin/cfssl
sudo mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

Check:
cfssl version

Installing HAProxy as kubeapi load balancer

On the kubeapi load balancer node (10.0.0.90) performing:
sudo apt install haproxy
then the configuration needs to be changed, editing /etc/haproxy/haproxy.cfg:

global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon

# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private

# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http

# PART BEFORE IS NOT CHANGED, ONLY THE FOLLOWING ADDED:

frontend kubernetes
bind 10.0.0.90:6443
option tcplog
mode tcp
default_backend kubernetes-master-nodes

backend kubernetes-master-nodes
mode tcp
balance roundrobin
option tcp-check
server master01 10.0.0.71:6443 check fall 3 rise 2
server master02 10.0.0.72:6443 check fall 3 rise 2
server master03 10.0.0.73:6443 check fall 3 rise 2

applying configuration:

sudo systemctl restart haproxy

Creating a CA and generating the certificates

Create a file for the certification authority configuration ca-config.json with the following content:

{
"signing": {
"default": {
"expiry": "8760h"
},
"profiles": {
"kubernetes": {
"usages": ["signing", "key encipherment", "server auth", "client auth"],
"expiry": "8760h"
}
}
}
}

Create the certificate authority signing request file ca-csr.json with the following content:

{
"CN": "Kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "IN",
"L": "Ukraine",
"O": "Organization",
"OU": "CA",
"ST": "State"
}
]
}

Generate the certificate authority certificate and private key:
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
Check if the files appeared in the current directory.

Generate the certificate for the Etcd cluster, make the certificate signing request configuration file kubernetes-csr.json with the following content:

{
"CN": "Kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "IN",
"L": "Ukraine",
"O": "Organization",
"OU": "CA",
"ST": "State"
}
]
}

and generate the certificate and private key, to the -hostname add you IPs of HAProxy kubeapi load balancer and master nodes:

cfssl gencert \
-ca=ca.pem \
-ca-key=ca-key.pem \
-config=ca-config.json \
-hostname=10.0.0.90,10.0.0.71,10.0.0.72,10.0.0.73,127.0.0.1,kubernetes.default \
-profile=kubernetes kubernetes-csr.json | \
cfssljson -bare kubernetes

Check if the files appeared.

Copy certificates ca.pem, kubernetes.pem and kubernetes-key.pem to each node, for example to the /home/user directory.

Preparing master nodes and setting up required packages

On all the master nodes:

sudo apt-get remove docker docker-engine docker.io containerd runc

sudo apt-get install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"sudo apt-get remove docker docker-engine docker.io containerd runc

sudo apt-get install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"

sudo apt-get install -y docker-ce docker-ce-cli containerd.io

sudo usermod -aG docker ubuntu

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

sudo mkdir -p /etc/apt/keyrings/
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

swapoff -a

and remove swap from /etc/fstab.

Setting up the Etcd high available cluster

On the master nodes:

sudo mkdir /etc/etcd /var/lib/etcd
sudo mv ~/ca.pem ~/kubernetes.pem ~/kubernetes-key.pem /etc/etcd
wget https://github.com/etcd-io/etcd/releases/download/v3.4.13/etcd-v3.4.13-linux-amd64.tar.gz
tar xvzf etcd-v3.4.13-linux-amd64.tar.gz
sudo mv etcd-v3.4.13-linux-amd64/etcd* /usr/local/bin/

create the Etcd systemd unit file by editing /etc/systemd/system/etcd.service

[Unit]
Description=etcd
Documentation=https://github.com/coreos

[Service]
ExecStart=/usr/local/bin/etcd \
--name 10.0.0.71 \
--cert-file=/etc/etcd/kubernetes.pem \
--key-file=/etc/etcd/kubernetes-key.pem \
--peer-cert-file=/etc/etcd/kubernetes.pem \
--peer-key-file=/etc/etcd/kubernetes-key.pem \
--trusted-ca-file=/etc/etcd/ca.pem \
--peer-trusted-ca-file=/etc/etcd/ca.pem \
--peer-client-cert-auth \
--client-cert-auth \
--initial-advertise-peer-urls https://10.0.0.71:2380 \
--listen-peer-urls https://10.0.0.71:2380 \
--listen-client-urls https://10.0.0.71:2379,http://127.0.0.1:2379 \
--advertise-client-urls https://10.0.0.71:2379 \
--initial-cluster-token etcd-cluster-0 \
--initial-cluster 10.0.0.71=https://10.0.0.71:2380,10.0.0.72=https://10.0.0.72:2380,10.0.0.73=https://10.0.0.73:2380 \
--initial-cluster-state new \
--data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Reload the daemon configuration, enable and start Etcd:

sudo systemctl daemon-reload
sudo systemctl enable etcd
sudo systemctl start etcd

Check it is running and clustered:
ETCDCTL_API=3 etcdctl member list
The output has to be like that:

25e141cd5630aead, started, 10.0.0.73, https://10.0.0.73:2380, https://10.0.0.73:2379, false
4e7196ec0c691986, started, 10.0.0.71, https://10.0.0.71:2380, https://10.0.0.71:2379, false
a02a3223c1119bbf, started, 10.0.0.72, https://10.0.0.72:2380, https://10.0.0.72:2379, false

Initialization of the master nodes

On the master nodes create a file config.yaml with the following content:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.29.3
controlPlaneEndpoint: "10.0.0.90:6443"
etcd:
external:
endpoints:
- https://10.0.0.71:2379
- https://10.0.0.72:2379
- https://10.0.0.73:2379
caFile: /etc/etcd/ca.pem
certFile: /etc/etcd/kubernetes.pem
keyFile: /etc/etcd/kubernetes-key.pem
networking:
podSubnet: 10.30.0.0/24
apiServer:
certSANs:
- "10.0.0.90"
extraArgs:
apiserver-count: "3"

Where 10.0.0.7x – our master nodes, 10.0.0.90 – certification authority (that is on HAproxy kubeapi load balancer VM), and 10.30.0.0/24 – subned for pods.

Copy file config.yaml to the other master nodes!

Initialise kubeadm on the first master node (10.0.0.71):
sudo kubeadm init --config=config.yaml

In case the preflight check is failing with the following message:

[init] Using Kubernetes version: v1.29.3
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR CRI]: container runtime is not running: output: time="2024-03-25T17:44:49Z" level=fatal msg="validate service connection: validate CRI v1 runtime API for endpoint \"unix:///var/run/containerd/containerd.sock\": rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService"
, error: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

remove /etc/containerd/config.toml and restart containerd.service:

sudo rm /etc/containerd/config.toml
sudo systemctl restart containerd

it also may fail if the firewall restrictions in action, do the following:

sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --permanent --add-port=2379-2380/tcp
sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=10251/tcp
sudo firewall-cmd --permanent --add-port=10252/tcp
sudo firewall-cmd --permanent --add-port=10255/tcp
sudo firewall-cmd –reload

Once all the preflight checks are passed, the initialization should be performed well, repeat the kubeadm init as above.

Then we have to copy the certificates /etc/kubernetes/pki from the first (10.0.0.71) master node to two others.


sudo scp -r /etc/kubernetes/pki [email protected]:~
sudo scp -r /etc/kubernetes/pki [email protected]:~

On the second (master02, 10.0.0.72) and third (master03, 10.0.0.73) master nodes remove apiserver.crt and apiserver.key:
rm ./pki/apiserver.
and move the certificates to the /etc/kubernetes directory:
sudo mv ~/pki /etc/kubernetes/

Perform the same initialization of the rest of master nodes (master02 and master03) with the file config.yaml we copied previously from the first master node (master01):
sudo kubeadm init --config=config.yaml

By the initialization of the masters you will get the following message:

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of control-plane nodes by copying certificate authorities
and service account keys on each node and then running the following as root:

kubeadm join 10.0.0.90:6443 --token kzw57k.x5mitlly89nhobrd \
--discovery-token-ca-cert-hash sha256:d7f3b00c8b71c39f81d92227f32217c24d26f0f1e821c5151387be49ff7d1e05 \
--control-plane

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.0.0.90:6443 --token kzw57k.x5mitlly89nhobrd \
--discovery-token-ca-cert-hash sha256:d7f3b00c8b71c39f81d92227f32217c24d26f0f1e821c5151387be49ff7d1e05

Save the part that describes how to join nodes to the cluster.

By the following command you have to see all your 3 masters in the output:
kubectl get nodes
it should look like that:

NAME STATUS ROLES AGE VERSION
master01 NotReady control-plane 66m v1.29.1
master02 NotReady control-plane 46m v1.29.3
master03 NotReady control-plane 44m v1.29.3

and after some time

NAME STATUS ROLES AGE VERSION
master01 Ready control-plane 3h15m v1.29.1
master02 Ready control-plane 175m v1.29.3
master03 Ready control-plane 173m v1.29.3

To initialize the worker nodes, perform on each output you saved when it was initialization of master nodes:

kubeadm join 10.0.0.90:6443 --token kzw57k.x5mitlly89nhobrd \
--discovery-token-ca-cert-hash sha256:d7f3b00c8b71c39f81d92227f32217c24d26f0f1e821c5151387be49ff7d1e05

then you can check your nodes appeared in output of the kubectl get nodes command as previously masters nodes do.

Deploying the CNI to have the overlay network

In this example we will use Calico, but you are free to use any of existing ones.

Download and install the manifest:

curl https://calico-v3-25.netlify.app/archive/v3.25/manifests/calico.yaml -O
kubectl apply -f calico.yaml
kubectl get pods -n kube-system

Setting up the ingress controller

We will use the nginx ingress controller, but you are free to use any of exsiting ones.

git clone https://github.com/nginxinc/kubernetes-ingress.git --branch v3.4.3
cd kubernetes-ingress/
kubectl apply -f deployments/common/ns-and-sa.yaml
kubectl apply -f deployments/rbac/rbac.yaml
kubectl apply -f examples/shared-examples/default-server-secret/default-server-secret.yaml
kubectl apply -f deployments/common/nginx-config.yaml
kubectl apply -f deployments/common/ingress-class.yaml
kubectl apply -f deployments/daemon-set/nginx-ingress.yaml
kubectl get pods --namespace=nginx-ingress

That’s all folks!

Как-то мне пришла идея использовать обычный shared хостинг с PHP для того, чтобы создать прокси сервер (а через него уже можно и в интернет ходить, и скрэпперы/кроулеры использовать).

Для этого нам понадобится Nginx с PHP, подойдёт даже работающий на локальном компьютере или же локально на виртуальной машине, а также любой shared хостинг, который поддерживает PHP (5.6 и новее).

Работает эта схема следующим образом: Nginx выступает в роли самого proxy сервера, который указываем в качестве прокси в браузере, PHP в связке с этим Nginx занимается приёмом запросов от браузера (или скрэппера/кроулера) и отправляет его на shared хостинг, где мы должны разместить файл Proxy.php из репозитория https://github.com/zounar/php-proxy

Этот скрипт можно немного по-вкусу модифицировать, например убрать аутентификаицю на уровне заголовков, передаваемых в скрипт (но можно и оставить для секьюрности), в своём примере я убрал для сокращения описания шагов. Но настройку http basic аутентификацию в nginx опишу.

Здесь не буду объяснять, как устанавливать nginx, а также PHP-FPM.

Настраиваем виртуальный хост nginx следующим образом:

server {
listen 3128;
server_name _;
root /home/user/webproxy;
index index.php;

auth_basic "Restricted";
auth_basic_user_file /home/user/web/.htpasswd; #файл с хешированным паролем для http basic аутентификации

location ~ \.php$ {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
}

location / {
rewrite ^/(.*)$ /index.php?url=$host$uri; #здесь передаём все запросы нашего браузера/скрэппера/кроулера путём get в переменную url
}
}

Скрипт, который нужно положить в /home/webproxy/index.php:

<?php

$url = $_GET['url'];

$request = curl_init('http://your-shared-hosting.xyz/Proxy.php'); //путь к файлу на shared хостинге

curl_setopt($request, CURLOPT_HTTPHEADER, array(
'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0',
'Proxy-Auth: SetInTheProxyPHPifEnabled',
'Proxy-Target-URL: https://'.$url
));

curl_exec($request);

?>

 

Менять можно по своему вкусу для сокрытия такого очевидного использования.

От хостинга требуется чтобы в PHP была поддержка libcurl, gzip и PHP safe_mode disabled (практически любой хостинг).

Получил недавно такую абузу:

Dear Sir or Madam,
>
> Multicast DNS (mDNS) is used for resolving host names to IP addresses
> within small networks that do not include a local DNS server. It is
> implemented for example by the Apple ‘Bonjour’ and Linux/BSD ‘Avahi’
> (nss-mdns) services. mDNS uses port 5353/udp.
>
> In addition to disclosing information about the system/network,
> mDNS services openly accessible from anywhere on the Internet can be
> abused for DDoS reflection attacks against third parties.
>
> Please find below a list of affected systems hosted on your network.
> The timestamp (timezone UTC) indicates when the openly accessible
> mDNS service was identified.
>
> We would like to ask you to check this issue and take appropriate
> steps to close the openly accessible mDNS services on the affected
> systems or notify your customers accordingly.
>
> If you have recently solved the issue but received this notification
> again, please note the timestamp included below. You should not
> receive any further notifications with timestamps after the issue
> has been solved.

Оказывается, на UDP порт 5353 слушал на всех интерфейсах avahi-daemon, который был установлен непонятно с чем (а может быть и по умолчанию в Linux Mint).

Смотрим, что слушает на этом порту:
netstat -tulpn |grep 5353
avahi-daemon

Побороть можно так следующим образом.

Проверяем зависимости, чаще всего avahi требует именно wine:

apt-rdepends wine | grep avahi

Если не нужен wine или зависимостей нет, то можно смело делать
apt-get remove avahi-daemon

Если нужен, то просто отключим:
update-rc.d avahi-daemon disable
/etc/init.d/avahi-daemon stop

Мне нравится утилита nethogs, которую я использую на своём сервере с Debian, для просмотра соединений и скорости передачи данных по процессам, но как-то она, после обновления, внезапно перестала работать, и стала выпадать с сообщением:

nethogs creating socket failed while establishing local IP — are you root?

Фикс такой:

wget -c https://github.com/raboof/nethogs/archive/v0.8.1.tar.gz
tar xf v0.8.1.tar.gz
cd ./nethogs-0.8.1/
sudo apt-get install libncurses5-dev libpcap-dev
make && sudo make install
sudo nethogs

Вот и всё.

sudo !! — запустить последнюю команду от имени рута. Полезно, если вы забыли добавить sudo в начале строки.

python -m SimpleHTTPServer — сделать доступной текущую директорию по адресу http://$HOSTNAME:8000/.

^foo^bar — выполнить предыдущую команду, но с заменой. Например, попробуйте запустить echo «tprogezr», а затем ^z.

ctrl-x e — зажать Ctrl и не отпуская x, затем e. Запускает редактор, чтобы можно было удобно составить большую сложную команду.

пробел команда — выполнить команду, но не запоминать её в истории.

‘ALT+.’ или ‘ .’ — поместить аргумент последней команды в консоль.

reset — восстановить терминал после вывода в него сырых бинарных данных или других ошибок формирования текста на экране.

mount | column -t — информация о текущих смонтированных файловых системах с удобным оформлением по столбцам.

echo “ls -l” | at midnight — выполнить команду в указанное время.

curl ifconfig.me — получить свой внешний IP.

ssh -N -L2001:localhost:80 somemachine — создать туннель от 80 порта на удалённой машине до 2001 на локальной.

man ascii — быстрый доступ к таблице ASCII.

dd if=/dev/dsp | ssh -c arcfour -C username@host dd of=/dev/dsp — перенаправить звук с вашего микрофона на колонки на удалённой машине.

arecord -f dat | ssh -C user@host aplay -f dat — более современный вариант предыдущей команды.

ctrl+u […] ctrl+y — запомнить текущую набираемую команду, а затем восстановить. Например, если в процессе набора команды вы что-то забыли, а затем хотите вернуться и продолжить.

wget -random-wait -r -p -e robots=off -U mozilla http://www.example.com — выкачать весь сайт.

curl -u user:pass -d status=”Tweeting from the shell” [http://twitter.com/statuses/update.xml]; — сделать твит через curl.

(cd /tmp && ls) — перейти к директории, выполнить там команду, вернуться к предыдущей директории.

Генерируем приватный ключ:

openssl genrsa -out /etc/exim/dkim.key 2048

На основе приватного, генерируем публичную часть ключа:

openssl rsa -in dkim.key -pubout

В текущей папке файл dkim.key – приватный ключ и тот хеш, что будет выведен на экран – публичный ключ.

Копируем содержимое публичного ключа и добавляем следующую запись в DNS для необходимого домена:

mailxxx._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=хеш_публичного_ключа_без_пробелов_и_переносов"

 

Копируем и добавляем её на NS сервер в зону нашего домена

 

Меняем права на приватный ключ, чтобы не было проблем с его доступностью для exim:

chmod 755 /etc/exim/dkim.key

 

Копируем конфигурационный файл exim себе, на случай некорректных изменений:

cp /etc/exim/exim.conf /home/login/

где login — ваш логин

 

Редактируем конфиг exim:

edit /etc/exim/exim.conf

 

Перед секцией remote_smtp добавляем следующее:

# DKIM
DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_FILE = /etc/exim/dkim.key
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}
DKIM_SELECTOR = mailxxx
DKIM_CANON = relaxed

 

В секции remote_smtp после директивы driver = smtp добавляем следующее:

dkim_domain = DKIM_DOMAIN
dkim_selector = mailxxx
dkim_private_key = DKIM_PRIVATE_KEY

 

Далее проверяем конфиг

exim -bV

 

и если нет ошибок, то перезапускаем exim:

/etc/init.d/exim restart

 

Проверяем, корректно ли работает подписывание DKIM ключём писем:

exim -v login@gmail.com

 

где вместо login — ваш логин (кэп), gmail.com — если у Вас почта на GMail

и вставляем туда примерно такой текст:

 

From: testmailbox@domain.com
To: login@gmail.com
Subject: Testing mail number1
Text of test message

 

Нажимаем Ctrl+D для отправки, смотрим лог события и выходим по Ctrl+C

В пришедшем письме в исходном сообщении (или по-другому говоря, оригинале) должна присутствовать запись о DKIM, похожая на это:

 

dkim=pass [email protected]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=domain.com; s=mailxxx;
	h=Date:Message-Id:Subject:To:From; bh=4va6Om8rQAC1qwOFl25GK4pspjLbTsksnYxam9/wNvU=;
	b=c7gPxW6HRILCS3xhlsRYa62SkSPzoAceCzcPDWUFynmUhjvElO/xAGIy3NV3k/RUxoPp2fA2OG6y1sUS5rEbMcW+tMZ0gU4ukO03rvodp9OWHixuV+OFCHih/JjZz2eF9kPPjoT02cD/5Ldj6BlZ77jQc/FGRkQX+1+RmxpFvzM=;

 

Обновляем список доступных пакетов
apt-get update

Устанавливаем OpenVPN
apt-get install openvpn

Защита соединения в OpenVPN в данном случае строится на использовании сертификатов и ключей для сервера и для клиентов. Для их генерации в пакете OpenVPN имеются специальные скрипты, расположенные в /usr/share/doc/openvpn/examples/easy-rsa/2.0 Перед началом работы скопируем их, чтобы не изменять оригиналы.

(для старых версий openvpn)

mkdir /etc/openvpn/easy-rsa
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa

С лета 2013 года easy-rsa не входит в OpenVPN и команда указанная выше не сработает(не найдет easy-rsa), тогда делаем доп команду:

sudo apt-get install easy-rsa

и копируем из другого места:

mkdir /etc/openvpn/easy-rsa
cp -r /usr/share/easy-rsa /etc/openvpn/easy-rsa
mv /etc/openvpn/easy-rsa/easy-rsa /etc/openvpn/easy-rsa/2.0

Переходим в созданную директорию, где и займёмся генерацией ключей и сертификатов

cd /etc/openvpn/easy-rsa/2.0

Редактируем файл переменных

nano vars

Здесь нужно добавить следующие строки:

# По умолчанию здесь просто openssl, которого нет в директории, в результате чего мы получим ошибку, если не укажем существующий. Я выбрал последнюю версию. Указывается без расширения .conf.
export OPENSSL=»openssl»

# В самом низу файла добавить
export KEY_ALTNAMES=»VPNsUS»

копируем конфиг openssl

cp openssl-1.0.0.cnf openssl.cnf

Загружаем переменные

source ./vars

Очищаем от старых сертификатов и ключей папку keys и создаем серийный и индексные файлы для новых ключей

./clean-all

Подтверждаем очистку.

Создаем сертификат. По умолчанию поля будут заполняться данными, введенными ранее в vars, поэтому можно ничего не менять.

./build-ca

Создаем ключ сервера

A challenge password []: Заполняется произвольным значением, насколько я понял это нужно только для создания ключа и больше нам не потребуется.

./build-key-server server

В конце соглашаемся с запросом на подпись и добавление сертификаты в базу.

Можно сразу создать ключи для клиента, перейдя в соответствующую часть статьи. Я вынес в отдельный раздел, т.к. ключи клиента могут генерироваться не один раз, чтобы было понятнее с чего начать в том случае когда нужно добавить клиента.

Создаем ключ Диффи Хельман

./build-dh

Cоздаем ключ для tls-аутификации

openvpn —genkey —secret keys/ta.key

Перемещаем сертификаты

cp -r /etc/openvpn/easy-rsa/2.0/keys/ /etc/openvpn/

Создание файла конфигурации сервера

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
cd /etc/openvpn
gunzip -d /etc/openvpn/server.conf.gz

nano /etc/openvpn/server.conf

port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh2048.pem
server 172.30.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth ta.key 0 # This file is secret
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
tls-server
tls-auth /etc/openvpn/keys/ta.key 0
tls-timeout 120
auth SHA1
cipher BF-CBC
push «redirect-gateway def1»
push «dhcp-option DNS 8.8.8.8»
status /var/log/openvpn-status.log
log /var/log/openvpn.log

Можно запускать наш сервер OpenVPN

service openvpn restart

В /etc/sysctl.conf расскомментируем #net.ipv4.ip_forward=1 после чего
echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl -p

iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -o venet0:0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -j SNAT —to 5.45.x.x
вместо venet0:0 указать имя внешнего интерфейса сервера (смотреть командой ifconfig),
вместо 5.45.x.x — указать внешний IP Вашего сервера,

iptables-save

Создание ключей и сертификатов

Ключи клиента создаются на сервере

Переходим в созданную директорию, где и замёмся генерацией ключей и сертификатов

cd /etc/openvpn/easy-rsa/2.0

Загружаем переменные

source vars

Создаем ключ клиента

Common Name (eg, your name or your server’s hostname) []: нужно вписать название файла ключа, в данном случае client

./build-key client

Если хотим защитить ключ паролем, то генерируем его другой командой, но в таком случае поднимать соединение автоматически не получится:

./build-key-pass client

Теперь нужно не забыть скопировать ключи (ca.crt, dh1024.pem, client.crt, client.key, ta.key) на клиента OpenVPN в /etc/openvpn/keys/

mv /etc/openvpn/keys/ /etc/openvpn/keys_backup
mv /etc/openvpn/easy-rsa/2.0/keys/ /etc/openvpn/

Создание файла конфигурации клиента, это делается на домашнем компьютере в любом простом текстовом редакторе вроде блокнота:

client
dev tun
proto udp
remote 5.45.x.x 1194
resolv-retry infinite
ca ca.crt
cert client.crt
key client.key
tls-client
tls-auth ta.key 1
auth SHA1 # по-умолчанию. Можно MD5
cipher BF-CBC
remote-cert-tls server
comp-lzo
persist-key
persist-tun

вместо 5.45.x.x — нужно вписать внешний IP вашего сервера

И сохраняем с именем client.ovpn в отдельную папку, например «C:\Program Files\OpenVPN\config»

В этой же папке, где мы сохранили client.ovpn, создаём ещё 4 пустых файла, и называем их:
ca.crt
ta.key
client.crt
client.key

и заполняем их содержимым, которое берём из (текст копируем прямо из консоли)
cat /etc/openvpn/keys/ca.crt
cat /etc/openvpn/keys/ta.key
cat /etc/openvpn/keys/client.key
cat /etc/openvpn/keys/client.crt

Сохраняем и запускаем соединение.

Добавление в автозагрузку:

update-rc.d openvpn defaults

Для того, чтобы примонтировать WebDAV в FreeBSD 9.2 нам нужно установить порт:

pkg_add fusefs-sshfs

cd /usr/ports/sysutils/fusefs-wdfs/
make install clean

/usr/local/etc/rc.d/fusefs start

Создаём точку монтирования:

mkdir /home/user/yandex.disk

Монтируем таким образом:

wdfs https://webdav.yandex.ru /home/user/yandex.disk -o accept_sslcert,username=LOGIN,password=PASSWORD

Если нужно, чтобы пользователи могли монтировать, нужно проделать следующее:

sysctl vfs.usermount=1

chmod 766 /dev/fuse

chmod 766 /dev/fuse0

/usr/local/etc/rc.d/fusefs restart

Добавляем в автозагрузку:

echo ‘fusefs_enable=”YES”‘ >> /etc/rc.conf

Возможно, на каком-то из этапов понадобится подгрузить модуль:

kldload fuse_module/fuse.ko

Почему-то часто забываю как правильно написать формат команды в /etc/sudoers (во FreeBSD /usr/local/etc/sudoers), чтобы вызывать sudo su без ввода пароля, оставлю же это здесь:

user     ALL=(ALL) NOPASSWD: ALL