Servidor VPN na máquina systemd-nspawn

2

Estou tentando implantar um servidor VPN (eu escolho o sabor Openswan) em um contêiner systemd-nspawn em um pi de framboesa executando o Arch Linux. Por enquanto eu posso entrar no contêiner, ping, sai de dentro do contêiner (eu consegui trazer a Internet).

Aqui está o meu arquivo de configuração do systemd para o meu contêiner. (override.conf)

[Service]
ExecStart=
ExecStart=/usr/bin/systemd-nspawn \
    --quiet --keep-unit --boot --link-journal=try-guest \
   -D /usr/lib/machines/%I \
    --machine=%I

Edit: Eu crio uma configuração do openswan.nspawn e refatorio a configuração no arquivo de substituição.

Então, esse arquivo é assim:

[alarm@alarmpi ~]$ sudo cat /etc/systemd/nspawn/openswan.nspawn 
[Exec]
Capability=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

[Network]
Private=yes
VirtualEthernet=yes
Port=udp:500:500
Port=udp:4500:4500
Port=udp:1701:1701
Port=tcp:500:500
Port=tcp:4500:4500
Port=tcp:80:80

Meu container inicializa corretamente e os diferentes serviços relacionados ao openswan são spwan corretamente dentro do container:

$ systemctl status [email protected][email protected] - Container openswan
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/[email protected]
           └─override.conf
   Active: active (running) since lun 2016-07-04 11:36:55 CEST; 1 day 1h ago
     Docs: man:systemd-nspawn(1)
 Main PID: 15805 (systemd-nspawn)
   Status: "Container running."
   CGroup: /machine.slice/[email protected]
           ├─15805 /usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --private-network --network-veth --capability=CAP_NET_ADMIN --mach
           ├─init.scope
           │ └─15810 /usr/lib/systemd/...
           └─system.slice
             ├─console-getty.service
             │ └─15853 /sbin/agetty --no...
             ├─dbus.service
             │ └─15838 /usr/bin/dbus-dae...
             ├─openswan.service
             │ ├─18417 /bin/sh /usr/lib/...
             │ ├─18418 logger -s -p daem...
             │ ├─18419 /bin/sh /usr/lib/...
             │ ├─18420 /bin/sh /usr/lib/...
             │ ├─18423 /usr/lib/openswan...
             │ ├─18425 _pluto_adns -- <i...
             │ └─18426 /usr/lib/openswan...
             ├─systemd-journald.service
             │ └─15824 /usr/lib/systemd/...
             ├─systemd-logind.service
             │ └─15837 /usr/lib/systemd/...
             ├─systemd-networkd.service
             │ └─15839 /usr/lib/systemd/...
             ├─systemd-resolved.service
             │ └─15848 /usr/lib/systemd/...
             └─xl2tpd.service
               └─15844 /usr/bin/xl2tpd -D

I setup the container with --network-veth.

My question now, is how to actually like in docker "publish" those ports (udp 500/4500/1701) and make them available from outside the container?

Like:

Road warrior --> cloud --> Arch pi --> systemd-nspawn container --

I know this would be trivial to forward traffic using iptables but that's not what I want.

I maybe need to have a bridged setup?

Editar: usando a diretiva "Port", agora posso encaminhar o tráfego dentro do meu contêiner, ótimo! : D

O único problema que estou enfrentando agora é que o pluto está travando ao lidar com a Associação de Segurança (ISAKMP) com a seguinte mensagem:

"L2TP-PSK-NAT" [1] 178.50.79.197 # 1: ABORT em /build/openswan/src/openswan-2.6.47/programs/pluto/keys.c:488 "L2TP-PSK-NAT" [1] 178.50.79.197 # 1: ABORT em /build/openswan/src/openswan-2.6.47/programs/pluto/keys.c:488

Se tocar uma campainha para alguém, por favor me avise. Eu vou olhar o código quando tiver tempo ..

Continua ..

    
por Lion.24 05.07.2016 / 15:25

0 respostas