Założenia:

• Urządzenie z systemem Linux, z procesorem o architekturze AMD64 lub ARM64 (Tutaj Raspberry Pi 4 z systemem Debian 13)


• Baza danych - dowolna, obsługiwana przez Vaultwarden, tutaj będzie to SQLite, ale nic nie stoi na przeszkodzie, aby wcześniej zainstalować sobie MariaDB.


• Adres usługi to https://vaultwarden.home.arpa:8443


• Udostępnienie aplikacji Web-Vault


• Samopodpisany certyfikat x509 w celu uruchomienia Vaultwarden po SSL na porcie 8443


• Użytkownik, który może tworzyć organizacje: admin@home.arpa


• Domeny, na które można wykonywać rejestrację użytkowników: localhost, home.arpa

Instalacja paczek potrzebnych do działania

apt-get update && apt-get -y install curl git wget ssl-cert

Utworzenie użytkownika, na którym będzie działała usługa

adduser --system --shell /usr/sbin/nologin --comment "Vaultwarden User" --create-home --home /usr/lib/vaultwarden/ vaultwarden

adduser vaultwarden ssl-cert

Utworzenie katalogu z konfiguracją

mkdir -p /etc/vaultwarden/ && chown vaultwarden:vaultwarden /etc/vaultwarden && chmod 0750 /etc/vaultwarden

Utworzenie katalogu na dane oraz dla plików tymczasowych

mkdir -p /usr/lib/vaultwarden/data/ && chown vaultwarden:vaultwarden /usr/lib/vaultwarden/data && chmod 0750 /usr/lib/vaultwarden/data

mkdir -p /usr/lib/vaultwarden/data/tmp && chown vaultwarden:vaultwarden /usr/lib/vaultwarden/data/tmp && chmod 0750 /usr/lib/vaultwarden/data/tmp

Utworzenie katalogu dla logów

mkdir -p /var/log/vaultwarden && chown vaultwarden:vaultwarden /var/log/vaultwarden && chmod 0751 /var/log/vaultwarden

Konfiguracja rotacji logów

cat < /etc/logrotate/vaultwarden

/var/log/vaultwarden/vaultwarden.log {

        su vaultwarden vaultwarden

        rotate 60

        daily

        missingok

        copytruncate

        notifempty

        compress

        sharedscripts

        postrotate

                invoke-rc.d rsyslog rotate >/dev/null 2>&1 || true

        endscript

}

EOF

Wypakowanie plików z obrazu Dockera

W celu wypakowania plików niezbędnych do uruchomienia usługi można ręcznie pobrać każdą z warstw dostępnych w manifeście dla obrazu vaultwarden/server lub też skorzystać z przygotowanego skryptu powłoki (instalujac uprzednio jq apt-get install jq -y):

#!/usr/bin/env bash

DEST_WEB="/usr/lib/vaultwarden"

DEST_BIN="/usr/bin"

VAULTWARDEN_USER="vaultwarden"

VAULTWARDEN_GROUP="vaultwarden"

IMAGE="vaultwarden/server"

TAG="latest"

case "$(uname -m)" in

  x86_64)  ARCH="amd64" ;;

  aarch64) ARCH="arm64" ;;

  *) echo "Unsupported architecture, exiting..."; exit 1 ;;

esac

TARGET_DIR="web-vault"

TARGET_BIN="vaultwarden"



mkdir -p "$DEST_WEB"



echo "[*] Getting registry token..."

TOKEN=$(curl -s \

  "https://auth.docker.io/token?service=registry.docker.io&scope=repository:${IMAGE}:pull" \

  | jq -r '.token')



echo "[*] Fetching manifest list..."

MANIFEST_LIST=$(curl -s \

  -H "Authorization: Bearer ${TOKEN}" \

  -H "Accept: application/vnd.docker.distribution.manifest.list.v2+json" \

  "https://registry-1.docker.io/v2/${IMAGE}/manifests/${TAG}")



echo "[*] Selecting manifest for $ARCH..."

MANIFEST_DIGEST=$(echo "$MANIFEST_LIST" \

  | jq -r ".manifests[] | select(.platform.architecture == \"$ARCH\") | .digest")



if [[ -z "$MANIFEST_DIGEST" ]]; then

    echo "Error: no manifest for architecture '$ARCH'"

    exit 1

fi



echo "[*] Using manifest: $MANIFEST_DIGEST"



echo "[*] Fetching image manifest..."

MANIFEST=$(curl -s \

  -H "Authorization: Bearer ${TOKEN}" \

  -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \

  "https://registry-1.docker.io/v2/${IMAGE}/manifests/${MANIFEST_DIGEST}")



echo "[*] Downloading layers..."

rm -f layer_*.tar

i=0

for DIGEST in $(echo "$MANIFEST" | jq -r '.layers[].digest'); do

  i=$((i+1))

  FILE="layer_${i}.tar"

  echo "    - downloading $FILE ($DIGEST)"

  curl -s -L \

    -H "Authorization: Bearer ${TOKEN}" \

    "https://registry-1.docker.io/v2/${IMAGE}/blobs/${DIGEST}" \

    -o "$FILE"

done



echo "[*] Searching for '$TARGET_DIR' and '$TARGET_BIN' in layers..."

FOUND_DIR=0

FOUND_BIN=



for LAYER in layer_*.tar; do

    if [[ "$FOUND_DIR" -eq 0 ]]; then

        if tar -tf "$LAYER" | grep "${TARGET_DIR}/index.html"; then

            echo "[*] Found '$TARGET_DIR' in $LAYER — extracting to $DEST_WEB"

            tar -xf "$LAYER" -C "$DEST_WEB" "$TARGET_DIR"

            FOUND_DIR=1

        fi

    fi

    if [[ "$FOUND_BIN" -eq 0 ]]; then

        if tar -tf "$LAYER" | grep "${TARGET_BIN}"; then

            echo "[*] Found '$TARGET_BIN' in $LAYER — extracting to $DEST_BIN"

            tar -xf "$LAYER" -C "$DEST_BIN" "$TARGET_BIN"

            FOUND_BIN=1

        fi

    fi

    if [[ "$FOUND_DIR" -eq 1 && "$FOUND_BIN" -eq 1 ]]; then

        break

    fi

done



rm -f layer_*.tar



if [[ "$FOUND_DIR" -eq 0 || "$FOUND_BIN" -eq 0 ]]; then

    echo "Error: Could not find one or both targets ('$TARGET_DIR' and '$TARGET_BIN') in the image layers."

    exit 1

fi

echo "[*] Change permissions..."

chown $VAULTWARDEN_USER:$VAULTWARDEN_GROUP $DEST_WEB/$TARGET_DIR -R

chown $VAULTWARDEN_USER:$VAULTWARDEN_GROUP $DEST_BIN/$TARGET_BIN

echo "[+] Done!"

echo "→ Extracted files are in: $DEST_WEB and $DEST_BIN"

echo "  - Web Vault: $DEST_WEB/$TARGET_DIR"

echo "  - Binary: $DEST_BIN/$TARGET_BIN"

# ./dedocker-vaultwarden.sh 

[*] Getting registry token...

[*] Fetching manifest list...

[*] Selecting manifest for arm64...

[*] Using manifest: sha256:a24a108a90f6380a8f990308831025b038ee8df5d5be7f4c04922441ac7d6ff0

[*] Fetching image manifest...

[*] Downloading layers...

    - downloading layer_1.tar (sha256:2ae15a20160209c6fd6cff4886e4ba2e666fa5bedd7b54a2c0097ea6646f0273)

    - downloading layer_2.tar (sha256:45431c76674b0df695a222114e087abf9d53d313517bc2b072f06913e8c89dcd)

    - downloading layer_3.tar (sha256:7c614f5e5b12d769ab1c7209670d560dfa11dad61b1b47e205d239ba64a8b0e6)

    - downloading layer_4.tar (sha256:6043b4e5998fa5bb92ed2956636c3718d33dea6c277cdd7510d2f6814db914a7)

    - downloading layer_5.tar (sha256:389eb04f03834ad4fa7d5b2fa18ae377990943fffd16b96397bfae35dfa6a6ba)

[*] Searching for 'web-vault' and 'vaultwarden' in layers...

web-vault/index.html

[*] Found 'web-vault' in layer_4.tar — extracting to /usr/lib/vaultwarden

vaultwarden

[*] Found 'vaultwarden' in layer_5.tar — extracting to /usr/bin

[*] Change permissions...

[+] Done!

→ Extracted files are in: /usr/lib/vaultwarden nad /usr/bin

  - Web Vault: /usr/lib/vaultwarden/web-vault

  - Binary: /usr/bin/vaultwarden

cd /usr/lib/vaultwarden

/usr/bin/vaultwarden --version

Vaultwarden 1.35.2

Web-Vault 2025.12.1+build.3

Następnie możemy przystąpić do generowania certyfikatu SSL oraz konfiguracji usługi.

Generowanie klucza oraz certyfikatu

apt-get install -y openssl

openssl genrsa -out /etc/ssl/private/self-vaultwarden.home.arpa.key 4096

chgrp ssl-cert /etc/ssl/private/self-vaultwarden.home.arpa.key

chmod 0640 /etc/ssl/private/self-vaultwarden.home.arpa.key

openssl req -x509 -new \

  -key /etc/ssl/private/self-vaultwarden.home.arpa.key \

  -sha256 \

  -days 825 \

  -out /etc/ssl/certs/self-vaultwarden.home.arpa.crt \

  -subj "/CN=vaultwarden.home.arpa" \

  -addext "subjectAltName=DNS:vaultwarden.home.arpa"

chgrp ssl-cert /etc/ssl/certs/self-vaultwarden.home.arpa.crt 

chmod 0644 /etc/ssl/certs/self-vaultwarden.home.arpa.crt 

Vaultwarden wymaga klucza rsa do podpisywania tokenów, zaproszeń dla użytkowników czy też danych w bazie danych. Należy zatem wygenerować go:

openssl genrsa -out /etc/vaultwarden/rsa_key.pem 4096

chown vaultwarden:vaultwarden /etc/vaultwarden/rsa_key.pem

chmod 0600 /etc/vaultwarden/rsa_key.pem

Skonfigurujmy teraz Vaultwarden, według założeń:

cat <> /etc/vaultwarden/vaultwarden.conf

DATA_FOLDER=/usr/lib/vaultwarden/data

RSA_KEY_FILENAME=/etc/vaultwarden/rsa_key

WEB_VAULT_FOLDER=/usr/lib/vaultwarden/web-vault/

WEB_VAULT_ENABLED=true

DATABASE_URL=/usr/lib/vaultwarden/data/db.sqlite3

WEBSOCKET_ENABLED=false

WEBSOCKET_ADDRESS=0.0.0.0

WEBSOCKET_PORT=3012

PUSH_ENABLED=False

PUSH_INSTALLATION_ID=CHANGEME

PUSH_INSTALLATION_KEY=CHANGEME

DOMAIN=https://vaultwarden.home.arpa:8443

SENDS_ALLOWED=False

SIGNUPS_ALLOWED=True

SIGNUPS_VERIFY=False

SIGNUPS_DOMAINS_WHITELIST=localhost,home.arpa

ORG_CREATION_USERS=admin@home.arpa

INVITATIONS_ALLOWED=False

INVITATION_ORG_NAME=Snakeoil

EMAIL_CHANGE_ALLOWED=False

LOF_FILE=/var/log/vaultwarden/vaultwarden.log

LOG_LEVEL=error

ROCKET_ADDRESS=0.0.0.0

ROCKET_PORT=8443

ROCKET_TLS={certs="/etc/ssl/certs/self-vaultwarden.home.arpa.crt",key="/etc/ssl/private/self-vaultwarden.home.arpa.key"}

EOF

chown vaultwarden:vaultwarden /etc/vaultwarden/vaultwarden.conf

chmod 0640 /etc/vaultwarden/vaultwarden.conf

Pozostała tylko instalacja usługi oraz jej uruchomienie. W tym celu należy utworzyć jednostkę systemd w /etc/systemd/system/vaultwarden.service:

cat <> /etc/systemd/system/vaultwarden.service

[Unit]

Description=Vaultwarden server

After=network.target auditd.service



[Service]

RestartSec=5s

Type=simple

User=vaultwarden

Group=vaultwarden

EnvironmentFile=/etc/vaultwarden/vaultwarden.conf

WorkingDirectory=/usr/lib/vaultwarden

ExecStart=/usr/bin/vaultwarden

Restart=always

PrivateTmp=true

PrivateDevices=true

ProtectHome=true

NoNewPrivileges=true

ProtectSystem=strict

ReadOnlyPaths=/usr/lib/vaultwarden/web-vault/ /etc/vaultwarden

ReadWritePaths=/usr/lib/vaultwarden/data/ /var/log/vaultwarden/

LimitNOFILE=1048576

LimitNPROC=64



[Install]

WantedBy=multi-user.target

EOF

systemctl daemon-reload

systemctl enable --now vaultwarden.service

Sprawdzenie poprawności działania usługi

# ss -plnat |grep 8443

LISTEN 0      4096         0.0.0.0:8443       0.0.0.0:*     users:(("vaultwarden",pid=3147,fd=24))  



# systemctl status vaultvarden.service

● vaultwarden.service - Vaultwarden server

     Loaded: loaded (/etc/systemd/system/vaultwarden.service; enabled; preset: enabled)

     Active: active (running) since Sat 2026-01-24 10:50:33 CET; 1min 21s ago

 Invocation: ba3204b2476940c9b3d82cbbf64d2e35

   Main PID: 3147 (vaultwarden)

      Tasks: 13 (limit: 8749)

        CPU: 195ms

     CGroup: /system.slice/vaultwarden.service

             └─3147 /usr/bin/vaultwarden



Jan 24 10:50:33 r4pie vaultwarden[3147]: | This is an *unofficial* Bitwarden implementation, DO NOT use the   |

Jan 24 10:50:33 r4pie vaultwarden[3147]: | official channels to report bugs/features, regardless of client.   |

Jan 24 10:50:33 r4pie vaultwarden[3147]: | Send usage/configuration questions or feature requests to:         |

Jan 24 10:50:33 r4pie vaultwarden[3147]: |   https://github.com/dani-garcia/vaultwarden/discussions or        |

Jan 24 10:50:33 r4pie vaultwarden[3147]: |   https://vaultwarden.discourse.group/                             |

Jan 24 10:50:33 r4pie vaultwarden[3147]: | Report suspected bugs/issues in the software itself at:            |

Jan 24 10:50:33 r4pie vaultwarden[3147]: |   https://github.com/dani-garcia/vaultwarden/issues/new            |

Jan 24 10:50:33 r4pie vaultwarden[3147]: \--------------------------------------------------------------------/

Można już z powodzeniem utworzyć konta użytkowników i korzystać do woli. Podobny efekt, z tym, że automatycznie, można uzyskać wykonując polecenia:

sudo apt-get install -y ansible git

cat < /tmp/localhost_vars.yml

linux_vaultwarden_domain: vaultwarden.home.arpa

linux_vaultwarden_signups_domains_whitelist:

  - localhost

  - home.arpa

linux_vaultwarden_org_creation_users:

  - admin@home.arpa

EOF

ansible-pull \

  -U https://github.com/michalsternadel/linux_vaultwarden.git \

  -e @/tmp/localhost_vars.yml \

  local.yml

Zalecam skonfigurować Vaultwarden tak, aby słuchał jedynie na hoście lokalnym oraz wykorzystać reverse-proxy do udostępniania usługi z odpowiadnią terminacją SSL. Przy dużych wdrożeniach również rozsądniej byłoby zamiast SQLite użyć silnika MariaDB.

• Jedna podsieć dla klientów: 192.168.168.0/24


• Dostęp do serwera VPN na porcie 1194/TCP


• Dostęp do serwera VPN na porcie 1194/UDP


• Dostęp do serwera VPN na porcie 443/TCP


• Konfiguracja oparta tym razem o certyfikaty


• Możliwość połączeń pomiędzy klientami (również gdy jeden zestawi VPN innym kanałem od drugiego)

Co będzie nam potrzebne? Serwer z zewnętrznym adresem IP oraz zainstalowanym systemem operacyjnym Linux (już skonfigurowanym). Konfigurację przedstawię na bazie Debiana 11 i OpenVPN w wersji 2.5.1, ale nic oczywiście nie stoi na przeszkodzie, aby użyć innego Linuksa oraz starszej wersji OpenVPN (po drobnym dopasowaniu konfiguracji).

Rozpocznijmy od instalacji pakietów, które będziemy potrzebowali, a więc openvpn oraz easy-rsa:

apt update && apt install openvpn easy-rsa -y

Następnie przygotujmy wszelkie katalogi, certyfikaty oraz klucze:

mkdir -p /etc/openvpn/easyrsa && cd /etc/openvpn/easyrsa/

cp -R /usr/share/easy-rsa/* ./

mv vars.example vars

wget https://raw.githubusercontent.com/TinCanTech/easy-tls/master/easytls -O ./easytls && chmod +x easytls

Zmieńmy konfigurację w pliku vars według upodobań, zalecam zmienić okres ważności certyfikatu CA oraz certyfikatów serwera/klientów (EASYRSA_CA_EXPIRE oraz EASYRSA_CERT_EXPIRE), jeżeli VPN ma służyć do użytku wewnętrznego.

./easyrsa init-pki

./easyrsa build-ca # Podajmy hasło na przykład "cement15" i zapamiętajmy

./easyrsa gen-dh # Tutaj możemy zaparzyć kawę

./easyrsa gen-crl # Zapamiętane hasło potrzebne

./easytls init-tls

./easytls build-tls-crypt

./easyrsa build-server-full openvpnserver nopass # Jeszcze pamietać hasło należy

./easyrsa build-client-full klient1 # Hasło już prawie się zapomniało

./easyrsa build-client-full klient2 nopass

mkdir /etc/openvpn/ccd

touch /etc/openvpn/ipp.txt

Powyższe komendy wygenerują po kolei: certyfikat główny -- autoryzujący pozostałe certyfikaty, klucz Diffie-Hellmana, listę nieważnych certyfikatów, zainicjują klucze szyfrujące TLS, wygenerują i podpiszą certyfikat serwera bez hasła do klucza oraz dwa certyfikaty i klucze dla klientów z hasłem do kluczy.

Po wygenerowaniu stosownych plików możemy przygotować nasze pliki konfiguracyjne.

Server na porcie 1194/TCP:

cat << EOF > /etc/openvpn/server1194tcp.conf

local 0.0.0.0

lport 1194

proto tcp4

dev tun-ovpntcp1194

ca /etc/openvpn/easyrsa/pki/ca.crt

cert /etc/openvpn/easyrsa/pki/issued/openvpnserver.crt

key /etc/openvpn/easyrsa/pki/private/openvpnserver.key

dh /etc/openvpn/easyrsa/pki/dh.pem

topology subnet

server 192.168.168.0 255.255.255.0

client-config-dir /etc/openvpn/ccd

keepalive 15 120

remote-cert-tls client

tls-version-min 1.2

tls-crypt /etc/openvpn/easyrsa/pki/easytls/tls-crypt.key 0

tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256

tls-groups prime256v1

cipher AES-256-CBC

auth SHA256

persist-key

persist-tun

crl-verify /etc/openvpn/easyrsa/pki/crl.pem

status /etc/openvpn/status.log 20

status-version 3

management 127.0.0.1 11194

verb 0

push "explicit-exit-notify 1"

ifconfig-pool-persist /etc/openvpn/ipp.txt

route-metric 5

log-append /var/log/openvpn/openvpnserver.log

script-security 2

learn-address /etc/openvpn/learn-address.sh

push "redirect-gateway def1"

EOF

Server na porcie 443/TCP:

cat << EOF > /etc/openvpn/server443tcp.conf

local 0.0.0.0

lport 443

proto tcp4

dev tun-ovpntcp443

ca /etc/openvpn/easyrsa/pki/ca.crt

cert /etc/openvpn/easyrsa/pki/issued/openvpnserver.crt

key /etc/openvpn/easyrsa/pki/private/openvpnserver.key

dh /etc/openvpn/easyrsa/pki/dh.pem

topology subnet

server 192.168.168.0 255.255.255.0

client-config-dir /etc/openvpn/ccd

keepalive 15 120

remote-cert-tls client

tls-version-min 1.2

tls-crypt /etc/openvpn/easyrsa/pki/easytls/tls-crypt.key 0

tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256

tls-groups prime256v1

cipher AES-256-CBC

auth SHA256

persist-key

persist-tun

crl-verify /etc/openvpn/easyrsa/pki/crl.pem

status /etc/openvpn/status.log 20

status-version 3

management 127.0.0.1 10443

verb 0

push "explicit-exit-notify 1"

ifconfig-pool-persist /etc/openvpn/ipp.txt

route-metric 5

log-append /var/log/openvpn/openvpnserver.log

script-security 2

learn-address /etc/openvpn/learn-address.sh

push "redirect-gateway def1"

EOF

Server na porcie 1194/UDP:

cat << EOF > /etc/openvpn/server1194udp.conf

local 0.0.0.0

lport 1194

proto udp4

dev tun-ovpnudp1194

ca /etc/openvpn/easyrsa/pki/ca.crt

cert /etc/openvpn/easyrsa/pki/issued/openvpnserver.crt

key /etc/openvpn/easyrsa/pki/private/openvpnserver.key

dh /etc/openvpn/easyrsa/pki/dh.pem

topology subnet

server 192.168.168.0 255.255.255.0

client-config-dir /etc/openvpn/ccd

keepalive 15 120

remote-cert-tls client

tls-version-min 1.2

tls-crypt /etc/openvpn/easyrsa/pki/easytls/tls-crypt.key 0

tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256

tls-groups prime256v1

cipher AES-256-CBC

auth SHA256

persist-key

persist-tun

crl-verify /etc/openvpn/easyrsa/pki/crl.pem

status /etc/openvpn/status.log 20

status-version 3

management 127.0.0.1 21194

verb 0

push "explicit-exit-notify 1"

ifconfig-pool-persist /etc/openvpn/ipp.txt

route-metric 5

log-append /var/log/openvpn/openvpnserver.log

script-security 2

learn-address /etc/openvpn/learn-address.sh

push "redirect-gateway def1"

EOF

Teraz cala magia, bo jak każdy mało znudzony czytelnik zauważył, że przedstawione listingi posiadają linię server 192.168.168.0 255.255.255.0, a więc zostaną utworzone trzy różne interfejsy z taką samą adresacją. Musimy nauczyć nasz serwer jak trasować pakiety pomiędzy nimi, w zależności od tego, który klient połączy się do VPN z użyciem którego interfejsu. Za to odpowiedzialne są linie: script-security 2 (możliwość uruchamiana skryptów przez demona openvpn - ostrożnie) oraz learn-address /etc/openvpn/learn-address.sh.

Stwórzmy plik learn-address.sh oraz ustawmy mu atrybut +x:

cat << EOF > /etc/openvpn/learn-address.sh 

#!/bin/bash

if [ \$# -lt 2 ]; then

  exit 0;

fi

action=\$1;

addr=\$2;

commonname=\$3

case \${action} in

  add|update)

    /usr/bin/sudo /sbin/ip route del \${addr}/32 > /dev/null 2>&1

    /usr/bin/sudo /sbin/ip route add \${addr}/32 dev \${dev} > /dev/null 2>&1

  ;;

  delete)

    /usr/bin/sudo /sbin/ip route del \${addr}/32 > /dev/null 2>&1

  ;;

  *)

    exit 1

  ;;

esac

exit 0

EOF

chmod +x /etc/openvpn/learn-address.sh

Pozostaje nam uruchomić trzy demony OpenVPN:

systemctl enable openvpn@server1194tcp

systemctl enable openvpn@server443tcp

systemctl enable openvpn@server1194udp

systemctl start openvpn@server1194tcp

systemctl start openvpn@server443tcp

systemctl start openvpn@server1194udp

Upewniając się wcześniej, że konfiguracja firewalla jest odpowiednia (więc przekazywanie pakietów i NAT/Maskarada):

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT

iptables -A INPUT -i ens3 -p tcp --dport 1194 -j ACCEPT

iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT

iptables -A FORWARD -i ens3 -o tun-ovpntcp1194 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i ens3 -o tun-ovpntcp443 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i ens3 -o tun-ovpnudp1194 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -s 192.168.168.0/24 -o ens3 -j ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.168.0/24 ! -d 192.168.168.0/24 -o ens3 -j MASQUERADE

Jeżeli nigdzie nie popełniliśmy błędu, powinno wszystko wystartować i nasłuchiwać na skonfigurowanych portach, a my możemy przygotować konfiguracje dla klientów. Aby zautomatyzować sobie to trochę, posłużmy się poniższymi komendami:

mkdir -p /etc/openvpn/configs/

cat << EOF > /etc/openvpn/user-skeleton.conf

tls-client

pull

dev tun0

resolv-retry infinite

nobind

remote-cert-tls server

tls-version-min 1.2

key-method 2

verify-x509-name openvpnserver name

cipher AES-256-CBC

auth SHA256

auth-nocache

verb 0

redirect-gateway def1

key-direction 1

EOF



cat < /etc/openvpn/makeuserconfig.sh

#!/bin/bash

if [ -z \${1} ]; then

echo "No podajże nazwę klienta chociaż. Na ten przykład: \${0} klient1 port protokół"

echo "\${0} klient1 1194 tcp"

exit 1

fi

REMOTE=ABC.DEF.GHI.JKL # TUTAJ WKLEJAMY ZEWNĘTRZNE IP SERWERA

klient=\${1}

port=\${2}

proto=\${3}

outdir="/etc/openvpn/configs/"

template="/etc/openvpn/user-skeleton.conf"



echo "remote \${REMOTE} \${port}" >  \${outdir}\${klient}-\${port}-\${proto}.conf

if [ "\${proto}" == "udp" ] || [ "\${proto}" == "UDP" ] ; then

echo "proto udp4" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

else

echo "proto tcp4-client" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

fi

cat \${template} >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

cat /etc/openvpn/easyrsa/pki/ca.crt  >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo ""  >>  \${outdir}\${klient}-\${port}-\${proto}.conf

cat /etc/openvpn/easyrsa/pki/issued/\${klient}.crt >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

cat /etc/openvpn/easyrsa/pki/private/\${klient}.key >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

cat /etc/openvpn/easyrsa/pki/easytls/tls-crypt.key >>  \${outdir}\${klient}-\${port}-\${proto}.conf

echo "" >>  \${outdir}\${klient}-\${port}-\${proto}.conf

EOF

chmod +x /etc/openvpn/makeuserconfig.sh

Oraz wygenerujmy konfiguracje dla dwóch klientów (klient1 oraz klient2):

/etc/openvpn/makeuserconfig.sh klient1 1194 TCP

/etc/openvpn/makeuserconfig.sh klient1 1194 UDP

/etc/openvpn/makeuserconfig.sh klient1 443 TCP

/etc/openvpn/makeuserconfig.sh klient2 1194 TCP

/etc/openvpn/makeuserconfig.sh klient2 1194 UDP

/etc/openvpn/makeuserconfig.sh klient2 443 TCP

Należy mieć na uwadze, że tutaj openvpn musi być uruchomiony z użytkownika, który posiada uprawnienia do zmiany tablicy routingu, co siłą rzeczy niesie ze sobą pewne ryzyko, dotyczące bezpieczeństwa takiego rozwiązania. Rozważyć należy zatem czy warto jest podejmować to ryzyko. W obecnym przykładzie demony OpenVPN startują jako użytkownik root, ale w celu podniesienia bezpieczeństwa zachęcam do stworzenia odrębnego użytkownika systemowego, na którego prawach będzie działał OpenVPN, a któremy to z kolei przyznamy prawa do edycji tablicy routingu, czy to za pomocą sudo czy też opowiednich capabilities. Poniżej przykład użycia rozwiązania opartego na użytkowniku "vpnmajster" z odpowiednim wpisem w sudoers.d/vpnmajster.

Utwórzmy użytkownika vpnmajster:

adduser --system --disabled-login --disabled-password --no-create-home vpnmajster

Następnie stwórzmy plik /etc/sudoers.d/vpnmajster z odpowiednimi uprawnieniami:

cat < /etc/sudoers.d/vpnmajster

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-2][0-9][0-9]/32 dev tun-ovpntcp1194

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-2][0-9][0-9]/32 dev tun-ovpnudp1194

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-2][0-9][0-9]/32 dev tun-ovpntcp443

vpnmajster ALL = NOPASSWD:/sbin/ip route del 192.168.168.[1-2][0-9][0-9]/32

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-9][0-9]/32 dev tun-ovpntcp1194

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-9][0-9]/32 dev tun-ovpnudp1194

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-9][0-9]/32 dev tun-ovpntcp443

vpnmajster ALL = NOPASSWD:/sbin/ip route del 192.168.168.[1-9][0-9]/32

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-9]/32 dev tun-ovpntcp1194

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-9]/32 dev tun-ovpnudp1194

vpnmajster ALL = NOPASSWD:/sbin/ip route add 192.168.168.[1-9]/32 dev tun-ovpntcp443

vpnmajster ALL = NOPASSWD:/sbin/ip route del 192.168.168.[1-9]/32

EOF

chmod 0440 /etc/sudoers.d/vpnmajster

Dodajmy stosowną linijkę do plików konfiguracyjnych serwera oraz zrestartujmy usługę openvpn:

echo "user vpnmajster" >> /etc/openvpn/server1194tcp.conf

echo "user vpnmajster" >> /etc/openvpn/server1194udp.conf

echo "user vpnmajster" >> /etc/openvpn/server443tcp.conf

systemctl restart openvpn@server1194tcp

systemctl restart openvpn@server443tcp

systemctl restart openvpn@server1194udp

Gotowe. Czyż życie nie staje się proste po przeczytaniu zagmatwanego opisu?

• #12
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:37:25
• #11
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:36:50
• #10
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:36:21
• #9
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:35:54
• #8
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:35:33
• #7
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:35:25
• #6
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:34:57
• #5
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:34:40
• #4
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:34:26
• #3
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:30:50
• #2
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:30:29
• #1
  Autor: Stefan
  Treść: Skomplikowane
  Dodano: 11.10.2022, 19:29:51

• #2
  Autor: 121
  Treść: 2342
  Dodano: 28.01.2020, 11:07:26
• #1
  Autor: ttt
  Treść: tt
  Dodano: 28.01.2020, 11:04:50

• #4
  Autor: dfs
  Treść: sfd
  Dodano: 21.12.2020, 10:33:46
• #3
  Autor: dfs
  Treść: sfd
  Dodano: 21.12.2020, 10:31:49
• #2
  Autor: dfs
  Treść: sfd
  Dodano: 21.12.2020, 10:30:33
• #1
  Autor: dfs
  Treść: sfd
  Dodano: 21.12.2020, 10:25:51

Wtyczka umożliwia wyświetlanie aktualnie spędzonego czasu na kursie, ustawienia minimalnego limitu czasu dla kursu, po którego osiągnięciu przez studenta, opiekun może zostać powiadomiony za pośrednictwem e-maila, a system generuje szablon certyfikatu w formacie RTF.

Instalacja modułu jest jak zwykle prosta i można ją wykonać po staroświecku, czyli, wypakowując zawartość załącznika do folderu /blocks/, a następnie przechodząc pod adres konsoli administracyjnej, lub bezpośrednio z panelu administracyjnego platformy.

Aktualizacja z wersji poprzedniej automatycznie ustawia odpowiednie opcje konfiguracyjne (loglegacy i loglifetime).

Do prawidłowego działania moduł wymaga załączenia opcji: enablestats, logstore_legacy | loglegacy, loglifetime (nie usuwaj logów).

Poniżej przedstawię opisową instrukcję jak taką bramkę skonstruować i cieszyć się alertami SMS o zatrzymaniu się krytycznych usług na serwerze aplikacji o godzinie 3:20 w nocy.

Aby w ogóle rozpocząć budowę urządzenia, potrzebne nam będzie:

• Raspberry Pi (ja używałem Raspberry Pi Model B+ 512MB RAM)


• Karta microSD (ja użyłem 8GB)


• Modem GSM na USB, zarówno Huaweii E173 jak i E3551/E3131 działają wspaniale


• Zasilanie 5V (1A wystarczy w zupełności)


• Według kaprysu: obudowa, przedłużacze USB, karta WiFi na USB

Na samym początku musimy przygotować sobie system operacyjny - oczywiście będzie to Debian dla Raspberry Pi. Polecam od razu wersję lite. Instalację systemu na karcie wykonujemy zgodnie z instrukcją zawartą na stronie raspberrypi.org (w skrócie, dla Linuksa:

unzip yyyy-mm-dd-raspbian-jessie-lite.zip; dd bs=4M if=yyyy-mm-dd-raspbian-jessie-lite.img of=/dev/mmcblko0

Następnie łączymy się z komputerkiem, albo bezpośrednio klawiaturą i monitorem, albo przez sieć, wpinając kabel sieciowy do swojego switcha/komputera, albo przez kabel szeregowy. Wstępnie konfigurujemy system: sudo raspi-config Ustawiając Hostname, Locale oraz dostęp przez SSH.

Konfigurujemy sieć, zgodnie z życzeniem, ja zalecam dodać sobie adres IP do zarządzania (w przypadku gdy nie uda nam się ustalić jakie IP otrzymała bramka, gdy działa bez monitora). Do pliku /etc/network/interfaces można dodać:

auto eth0:0

iface eth0:0 inet static

    name failback

    address 192.168.139.253

    netmask 255.255.255.0

    network 192.168.139.0

Można przystąpić do instalacji niezbędnego oprogramowania. Zalecam jeszcze od razu dodanie repozytorium pakietów, które da nam możliwość instalacji PHP w wersji 7.0 (skrypty uruchamiają się o wiele szybciej). Do pliku /etc/apt/sources trzeba dopisać:

deb http://repozytorium.mati75.eu/raspbian jessie-backports main contrib non-free

deb-src http://repozytorium.mati75.eu/raspbian jessie-backports main contrib non-free

sudo gpg --keyserver pgpkeys.mit.edu --recv-key CCD91D6111A06851

sudo gpg --armor --export CCD91D6111A06851 | sudo apt-key add -

apt update

apt install nginx php7.0 php7.0-curl php7.0-gd php7.0-imap php7.0-json php7.0-mcrypt php7.0-mysql php7.0-mysqli php7.0-opcache php7.0-readline php7.0-fpm php7.0-xml php7.0-mbstring mysql-server mysql-client git curl

echo "CREATE USER 'playsms'@'localhost' IDENTIFIED BY 'HasloKtoreZnaTylkoPrezydentRzeczypospolitejPolskiejIJestPrzyklejoneNaKlapieLaptopaSluzbowegoPokazywanegoBardzoCzestoWTelewizorze'; GRANT USAGE ON *.* TO 'playsms'@'localhost' REQUIRE NONE WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; CREATE DATABASE IF NOT EXISTS `playsms`; GRANT ALL PRIVILEGES ON `playsms`.* TO 'playsms'@'localhost';" | mysql -u root -p

Należy wpisać hasło root, oczywiście w tym przykładzie: PostaramSiePamietac2HaslaKtoreUzywamDoTwitera&fejsbuka

Teraz możemy pobrać i zainstalować playSMS:

mkdir -p /var/www/

cd /var/www/

wget http://downloads.sourceforge.net/project/playsms/playsms/Version%201.4/playsms-1.4.tar.gz

tar zxf playsms-1.4.tar.gz

ln -s playsms-1.4 playsms

cd playsms

cp install.conf.dist install.conf

nano install.conf

rm playsms-1.4.tar.gz

DBUSER="playsms", DBPASS="HasloKtoreZnaTylkoPrezydentRzeczypospolitejPolskiejIJestPrzyklejoneNaKlapieLaptopaSluzbowegoPokazywanegoBardzoCzestoWTelewizorze", DBNAME="playsms", DBHOST="localhost", PATHWEB="/var/www/playsms".

$core_config['db']['type'] = 'mysql';

$core_config['db']['type'] = 'mysqli';

server {

listen 80 default_server;

listen [::]:80 default_server;

root /var/www/playsms;

index index.php index.html index.htm;

server_name _;

location / {

try_files $uri $uri/ =404;

}

location ~ \.php$ {

    fastcgi_split_path_info ^(.+\.php)(/.+)$;

    fastcgi_intercept_errors on;

fastcgi_pass unix:/var/run/php7.0-fpm.sock; # Dla php5 będzie tu inna ścieżka: /var/run/php5-fpm.sock;

    fastcgi_index index.php;

fastcgi_buffers 16 16k; 

fastcgi_buffer_size 32k;

    include fastcgi.conf;

}

location ~ /\.ht {

deny all;

}

}

ln -s /etc/nginx/sites-available/playsms /etc/nginx/sites-enabled

rm /etc/nginx/sites-enabled/default

nginx -t

Możemy przystąpić do instalacji i konfiguracji modemu GSM. Podłączamy modem do wolnego portu USB oraz wykonujemy poniższe komendy:

apt install gammu-smsd gammu usb-modeswitch

useradd -G gammu www-data

mkdir -p /var/log/gammu

chown gammu:gammu /var/log/gammu

chmod g+s /var/log/gammu

[gammu]

port = /dev/ttyUSB0

connection = at115200

logfile = /var/log/gammu/gammu.log

logformat = textall



[smsd]

Service = files

InboxPath = /var/spool/gammu/inbox/

OutboxPath = /var/spool/gammu/outbox/

SentSMSPath = /var/spool/gammu/sent/

ErrorSMSPath = /var/spool/gammu/error/

InboxFormat = unicode

OutboxFormat = unicode

TransmitFormat = auto

debugLevel = 0

LogFile = /var/log/gammu/smsd.log

DeliveryReport = no

CheckSecurity = 0

Aby modem zawsze był widziany jako modem (a nie np. jak CD-ROM) warto dodać odpowiednie reguły do udeva, aby przy podłączeniu uruchamiać usb_modeswitch. Poniżej zawartość dla obydwu wspomnianych w tekście modemów (plik /etc/udev/rules.d/80-gsm.rules

#E173:

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 1446 -V 12d1 -P 1506 -M '55534243123456780000000000000011062000000100000000000000000000'"

#E3131:

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14fe", RUN+="/usr/sbin/usb_modeswitch -v 12d1 -p 14fe -V 12d1 -P 1506 -M '55534243123456780000000000000011062000000100000000000000000000'"

Teraz konfiguracja samego playSMS za pośrednictwem interfejsu WWW. Trzeba zalogować się do playSMS przez przeglądarkę, wybrać Settings->Manage Gateway & SMSC, kliknąć na gammu manage oraz wpisać w Spool folder /var/spool/gammu i zapisać.

Następnie należy przejść w Settings -> Main Configuration i wybrać gammu dla Default SMSC

/usr/bin/curl "http://127.0.0.1/index.php?app=ws&u=UZYTKOWNIK1&h=TAJNYHASHUZYTKOWNIKA1&op=pv&to=004800000000&msg=Test&nofooter=1"

Czasem zdarza się tak, że jakiś SMS nie dojdzie na skutek nieokreślonego błędu w deamonie gammu-smsd. Niestety w obecnej wersji playsms nie ma mechanizmu, który automatycznie ponowi próbę wysyłki, dlatego też zastosujemy rozwiązanie pomocnicze, tworząc plik /usr/local/bin/resendSMS.sh, o następującej treści:

#!/bin/bash

/usr/bin/mysql -u playsms -pHasloKtoreZnaTylkoPrezydentRzeczypospolitejPolskiejIJestPrzyklejoneNaKlapieLaptopaSluzbowegoPokazywanegoBardzoCzestoWTelewizorze -hlocalhost playsms -N -e"SELECT id, p_dst as number, REPLACE(p_msg,'\n', '%0A') as message FROM playsms_tblSMSOutgoing WHERE p_status='2' ORDER BY c_timestamp DESC;" | while read id number message ; do

msg=`echo -e $message`

/usr/bin/curl -s -g "http://127.0.0.1/index.php?app=ws&u=UZYTKOWNIK1&h=TAJNYHASHUZYTKOWNIKA&op=pv&to=${number}&nofooter=1&msg=${msg}" && /bin/echo "UPDATE playsms.playsms_tblSMSOutgoing SET p_status='1' WHERE id ='$id'" | /usr/bin/mysql -u sys_playsms -pHasloKtoreZnaTylkoPrezydentRzeczypospolitejPolskiejIJestPrzyklejoneNaKlapieLaptopaSluzbowegoPokazywanegoBardzoCzestoWTelewizorze -hlocalhost playsms

done

exit 0

W skrypcie oczywiście należy zmienić UZYTKONIK i TAJNYHASHUZYTKOWNIKA na odpowiedni, zczytany z playsms, a następnie ustawić atrybut wykonywania chmod +x /usr/local/bin/resendSMS.sh

Teraz skrypt ten warto wykonywać co kilka minut (tutaj co 2 minuty), a wiec należy utworzyć plik /etc/cron.d/resendFailedSMS, zawierający:

*/2 * * * * root /usr/local/bin/resendSMS.sh > /dev/null 2>&1

Teraz pozostaje nam cieszyć się własną bramką SMS.

I tak w lustrzanym przyjacielu nastąpiło zrównanie czasu przeszłego z przyszłym, wykreowanie teraźniejszości, w której od wieków coś nie pasowało, było nadpsute, zatęchłe, ohydnie odpychające i trwa. To życie. Życie, ach, to... życie...

Wtyczka umożliwia wyświetlanie aktualnie spędzonego czasu na kursie, ustawienia minimalnego limitu czasu dla kursu, po którego osiągnięciu przez studenta, opiekun może zostać powiadomiony za pośrednictwem e-maila, a system generuje szablon certyfikatu w formacie RTF.

Instalacja modułu jest jak zwykle prosta i można ją wykonać po staroświecku, czyli, wypakowując zawartość załącznika do folderu /blocks/, a następnie przechodząc pod adres konsoli administracyjnej, lub bezpośrednio z panelu administracyjnego platformy.

Do prawidłowego działania moduł wymaga załączenia opcji: enablestats, logstore_legacy | loglegacy, loglifetime (nie usuwaj logów).

Starałem się, aby przedstawiona konfiguracja była elegancka, więc oparłem ją w całości o systemy typu Debian oraz wbudowane w nich mechanizmy konfiguracji. Bezproblemowo można jednak po staroświecku oskryptować sobie wszystko i uruchamiać przygotowany tak skrypt przy starcie systemu.

Co będzie potrzebne?

• Dwa lub więcej łącz u klienta (w poniżej przedstawionej konfiguracji będą trzy).


• Zewnętrzny serwer oparty na Linuksie w jakimś datacenter lub gdziekolwiek, z łączem szybszym lub równym sumie łącz klienckich oraz z odpowiednią pulą adresów zewnętrznych (jeden adres zewnętrzny dla jednego łącza klienta).


• Router kliencki oparty na Linuksie.


• Wkompilowana obsługa bondingu na serwerze oraz routerze klienckim lub moduł bond (Debian standardowo już to ma).

• Serwer
  
  
  
  • Łącze 100mbps/100mbps.
  
  
  • Jedna karta sieciowa (eth0).
  
  
  • Sieć 10.20.30.0/29, bramka: 10.20.30.1, dostępne adresy IP: 10.20.30.2, 10.20.30.3, 10.20.30.4, 10.20.30.5, 10.20.30.6.
  
  
  • Firewall z otwartym portem 5000 (dla vtun) oraz ustawioną maskaradą.
  
  
  • Adres 192.168.204.1/255.255.255.252 - adres interfejsu bond0, może być dowolny, prywatny, nie używany po żadnej stronie tunelów. Będzie to bramka domyślna dla routera klienckiego.
  
  
  
  


• Router kliencki
  
  
  
  • Łącze 10mbps/10mbps od Operatora1, Sieć 172.16.0.0/30, IP: 172.16.0.2, bramka: 172.16.0.1, maska: 255.255.255.252, wpięte do karty eth0
  
  
  • Łącze 4mbps/4mbps od Operatora2, Sieć 172.30.0.4/30, IP: 172.30.0.6, bramka: 172.30.0.5, maska: 255.255.255.252, wpięte do karty eth0
  
  
  • Łącze 5mbps/5mbps od Operatora3, Sieć 192.168.30.0/23, IP: 192.168.31.71, bramka: 192.168.30.1, maska: 255.255.254.0, wpięte do karty eth1
  
  
  • Trzy karty sieciowe (eth0, eth1 oraz eth2)
  
  
  • Sieć lokalna 192.168.1.0/24, skonfigurowany nat/maskarada na interfejsie eth2)
  
  
  • Adres 192.168.204.2/255.255.255.242 - adresu interfejsu bond0, dowolny, który koresponduje z podsiecią na interfejsie bond0 na serwerze.
    
  
  

Konfiguracja serwera w datacenter

Zacznijmy od przygotowania serwera w naszym datacenter. Najpierw zainstalujmy sobie odpowiednie oprogramowanie apt-get install ifenslave vtun, zmodyfikujmy w pliku /etc/network/interfaces odpowiednie interfejsy:

auto lo

iface lo inet loopback



# Pierwszy adres IP

auto eth0

iface eth0 inet static

  address 10.20.30.2

  netmask 255.255.255.248

  network 10.20.30.0

  broadcast 10.20.30.7

  gateway 10.20.30.1

  dns-nameservers 8.8.8.8 8.8.8.4



# Drugi adres IP

auto eth0:0

iface eth0:0 inet static

  address 10.20.30.3

  netmask 255.255.255.248

  network 10.20.30.0

  broadcast 10.20.30.7



# Trzeci adres IP 

auto eth0:1

iface eth0:1 inet static

  address 10.20.30.4

  netmask 255.255.255.248

  network 10.20.30.0

  broadcast 10.20.30.7



## Dla większej ilości adresów, można odpowiednio dopisać dodatkowe sekcje

 

# Agregacja lacza:

auto bond0

iface bond0 inet static

  address 192.168.204.1

  netmask 255.255.255.252

  bond-slaves tap11 tap12 tap13

  bond_mode balance-rr

Teraz stwórzmy konfigurację tunelu. W tym poradniku skorzystamy z vtun, ale jeśli jest Ci wygodniej, możesz użyć openvpn czy nawet ssh. W pliku /etc/vtund.conf powinny znaleźć się takie wpisy:

options {

  port 5000;

  ip /sbin/ip;

}

default {

 compress no;

 encrypt no;

 keepalive yes;

 proto tcp;

 speed 0;

}

TRUNK11 {

 passwd supertajnepierwszehaslodotuneluitrudnedozapamietaniazawierajacenajlepiejjedenznaknumeryczny;

 type ether;

 device tap11;

 up {

  ip "link set up %% multicast off mtu 1420";

  program "/sbin/ifenslave bond0 %%";

 };

}

TRUNK12 {

 passwd supertajnedrugiehaslodotuneluitrudnedozapamietaniazawierajacenajlepiejjedenznaknumeryczny;

 type ether;

 device tap12;

 up {

  ip "link set up %% multicast off mtu 1420";

  program "/sbin/ifenslave bond0 %%";

 };

}

TRUNK13 {

 passwd supertajnetrzeciehaslodotuneluitrudnedozapamietaniazawierajacenajlepiejjedenznaknumeryczny;

 type ether;

 device tap13;

 up {

  ip "link set up %% multicast off mtu 1420";

  program "/sbin/ifenslave bond0 %%";

 };

}

## Dla większej ilości tuneli, należy skopiować odpowiednio TRUNKXX, zmieniając niezbędne w środku parametry

## dodając również interfejs tap w /etc/network/interfaces: bond-slaves

Ustawmy w pliku /etc/default/vtun zmienną RUN_SERVER=yes, podnieśmy nowe interfejsy ifup bond0 (i jeżeli eth0:0 i eth0:1 zostały dodane, to również i je) oraz wystartujmy vtun: service vtun start.

Pamiętać należy, ażeby dodać natowanie/maskaradę na interfejsie bond0, dla przykładu:

iptables -A FORWARD -i bond0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -s 192.168.204.2/32 -j ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.204.2/32 ! -d 192.168.204.0/30 -o eth0 -j MASQUERADE

Konfiguracja routera

Przejdźmy do ustawień routera klienckiego. Tak samo jak w przypadku serwera, najpierw instalujemy niezbędne oprogramowanie: apt-get install vtun ifenslave, konfigurujemy interfejs bond0 w /etc/network/interfaces, pamiętając o niezbędnych wpisach routingu (jeśli ich nie mielismy wcześniej):

auto lo

iface lo inet loopback



# Operator1

auto eth0

iface eth0 inet static

  address 172.16.0.2

  netmask 255.255.255.252

  post-up ip route add 172.16.0.0/30 dev eth0 src 172.16.0.2 table link1

  post-up ip route add default via 172.16.0.1 table link1

  post-up ip rule add from 172.16.0.2 to all lookup link1

  post-up ip rule add from all to 172.16.0.2 lookup link1

  post-down ip route flush table link1

  post-down ip rule del from 172.16.0.2 to all lookup link1

  post-down ip rule del from all to 172.16.0.2 lookup link1



# Operator2

auto eth0:0

iface eth0:0 inet static

  address 172.30.0.6

  netmask 255.255.255.252

  post-up ip route add 172.30.0.4/30 dev eth0 src 172.30.0.6 table link2

  post-up ip route add default via 172.30.0.5 table link2

  post-up ip rule add from 172.30.0.6 to all lookup link2

  post-up ip rule add from all to 172.30.0.6 lookup link2

  post-down ip route flush table link2

  post-down ip rule del from 172.30.0.6 to all lookup link2

  post-down ip rule del from all to 172.30.0.6 lookup link2



# Operator3

auto eth1

iface eth1 inet static

  address 192.168.31.71

  netmask 255.255.254.0

  post-up ip route add 192.168.31.0/24 dev eth0 src 192.168.31.71 table link3

  post-up ip route add default via 192.168.30.1 table link3

  post-up ip rule add from 192.168.31.71 to all lookup link3

  post-up ip rule add from all to 192.168.31.71 lookup link3

  post-down ip route flush table link3

  post-down ip rule del from 192.168.31.71 to all lookup link3

  post-down ip rule del from all to 192.168.31.71 lookup link3



## Dla większej ilosci łącz można dodać więcej odpowiednich sekcji

 

# Agregacja łącza

auto bond0

iface bond0

  address 192.168.204.2

  netmask 255.255.255.252

  gateway 192.168.204.1

  dns-nameservers 8.8.8.8 8.8.4.4

  bond-slaves tap11 tap12 tap13

  bond_mode balance-rr

 

# Sieć lokalna

auto eth2

iface eth2 inet static

  address 192.168.1.1

  netmask 255.255.255.0

  network 192.168.1.0

  broadcast 192.168.1.255

Następnie w pliku /etc/iproute2/rt_tables, dodajemy adekwatne wpisy (jeśli ich jeszcze nie mieliśmy):

11 link1

12 link2

13 link3

## można dodać więcej analogicznych wpisów, w przypadku chęci dodania większej ilości łącz

Uruchamiamy interfejsy: ifup bond0 (itd), a następnie edytujemy plik /etc/vtund.conf:

options {

 port 5000;

 ip /sbin/ip;

}

default {

 compress no;

 encrypt no;

 stat yes;

 speed 0;

}

TRUNK11 {

 passwd supertajnepierwszehaslodotuneluitrudnedozapamietaniazawierajacenajlepiejjedenznaknumeryczny;

 device tap11;

 persist yes;

 srcaddr {

  iface eth0;

  addr 172.16.0.2;

 };

 up {

  ip "link set %% up multicast off mtu 1460";

  program "/sbin/ifenslave bond0 %%";

 };

}

TRUNK12 {

 passwd supertajnedrugiehaslodotuneluitrudnedozapamietaniazawierajacenajlepiejjedenznaknumeryczny;

 device tap12;

 persist yes;

 srcaddr {

  iface eth0;

  addr 172.30.0.6;

 };

 up {

  ip "link set %% up multicast off mtu 1460";

  program "/sbin/ifenslave bond0 %%";

 };

}

TRUNK13 {

 passwd supertajnetrzeciehaslodotuneluitrudnedozapamietaniazawierajacenajlepiejjedenznaknumeryczny;

 device tap13;

 persist yes;

 srcaddr {

  iface eth1;

  addr 192.168.31.71;

 };

 up {

  ip "link set %% up multicast off mtu 1460";

  program "/sbin/ifenslave bond0 %%";

 };

}

## Dla większej ilości tuneli, analogicznie dodać należy więcej sekcji TRUNKXX z odpowiednimi parametrami

## dodając również interfejs tap w /etc/network/interfaces: bond-slaves

W pliku /etc/default/vtun umieszczamy wpisy:

CLIENTO_NAME=TRUNK11

CLIENT0_HOST=10.20.30.2

CLIENT1_NAME=TRUNK12

CLIENT1_HOST=10.20.30.3

CLIENT2_NAME=TRUNK13

CLIENT2_HOST=10.20.30.4

## dla większej ilości analogicznie.

Odpalamy tunel: service vtun start i jeżeli nasze trzy łącza klienckie są sprawne, maksymalna dostępna prędkość wyniesie 19mbps/19mbps. W przypadku awarii łącza od Operatora 1, prędkość spadnie do 9mbps/9mbps.

Należy pamiętać, że w przypadku awarii serwera w naszym datacenter nie będziemy mieli możliwości dostać się do Internetu.

Tekst trochę zagmatwany, a jakże! Starałem się nie pisać tekstu dla osób jedynie klikających myszką, choć pewnie mi trochę nie wyszło. Myślę jednak, że dla młodych administratorów, chcących coś zagregować tekst będzie świetnym punktem początkowym, a być może również i końcowym w poszukiwaniach ciekawych rozwiązań.

• #5
  Autor: Marek
  Treść: @Michał Sternadel: Serwer DC ma link 100Mbit/100Mbit. Po mojej stronie mam 2 x LTE (10Mbit/10Mbit oraz 40Mbit/10Mbit). Prędkość nie jest najważniejsza, równoważenie obciążenia - bezcenne ;)
  Tryb balance-alb 6 jest obiecujący - przetestuje. Pozdrawiam
  Dodano: 26.12.2016, 22:22:41
• #4
  Autor: Michał Sternadel
  Treść: @Mateusz: Jak napisał poniżej Marek, to para prywatnych adresów IP, aby serwer w DC oraz router kliencki się widziały. Może to być cokolwiek, nieużywanego w sieci lokalnej po jednej i drugiej stronie.
  @Marek: Prawdopodobnie prędkości sumują się poprawnie, LTE jest asymetryczne, stąd dane wysyłane z serwera do routera klienckiego chodzą po prędkości "upload". Mogę się jednak mylić. Spróbuj ramki jumbo (nic nie zaszkodzi, chociaż to bardziej pod interfejsy ethernetowe): ifconfig bond0 mtu 9000 up - oczywiście po dwóch stronach. Można też spróbować trybów: balance-xor, balance-tlb, balance-alb.
  Pozdrawiam
  Dodano: 26.12.2016, 20:16:33
• #3
  Autor: Marek
  Treść: Mam dwa łącza LTE (jedno około 10Mbit, drugie około 40Mbit). Test z odłączeniem kabelka działa - (przełącza między jednym a drugim). Natomiast transfer mam w granicach około 15Mbit. bond-mode balance-rr. Czy może jest jeszcze jakiś myk, który powoduje że te prędkości będą się sumowały ?
  
  P.S. (do Mateusza) Interfejs bond0 funkcjonuje na sieci 192.168.204.0/30. Nie potrzeba czwartego publicznego IP.
  Dodano: 26.12.2016, 19:43:23
• #2
  Autor: Mateusz
  Treść: Czołem. Fajny opis i fajne podejście do tematu
  
  Mam pytanko: w konfiguracji serwera i klienta dla bond0 pojawia się nagle adres 192.168.204.1 który nie został nigdzie opisany.
  
  Czy to jest adres używany jakoś wewnętrznie przy komunikacji pomiędzy vtunami na serwerze i kliencie? Czy potrzebuję tam podać czwarty publiczny adres IP serwera (dla konfiguracji z trzema łączami jak tutaj)? Czy może być taki prywatny jak w przykładzie i nie potrzebuję nadmiarowego IP?
  Dodano: 21.12.2016, 10:01:38
• #1
  Autor: 1912
  Treść: Człowieku skąd t się urwałeś?
  ale odpał, jesteś fenomenalny
  Dodano: 17.04.2015, 11:04:27

Modem Comtrend VI-3223u cierpi na ciekawą przypadłość, że bez względu na aktualne/historyczne obciążenie łącza, porę dnia, czy też trendy dotyczące nowych stron internetowych w sieci lubi się najeść bobem. Bób, mimo, że smaczny i pożywny często zatyka kiszki torując frajdę wynikającą z przeglądania najświeższych plotek ze świata i okolic. Po zalogowaniu się na modem i wejściu w statystyki widać, że łącze zestawione jest przyzwoicie, jednakże odczuwalna prędkość sugeruje, że raczej pakiety dostarcza urząd pocztowy średnio rozwiniętego kraju niż przechodzą one przez jakiekolwiek kable. Pozostaje nam zresetować modem, co rozłączy wszystkie dogadane sesje, radio przestanie grać, a my dostaniemy mnóstwo ostrzeżeń z nagiosa.

Okazuje się, że zamiast resetować modem bardzo pomaga mu od czasu do czasu wyczyszczenie statystyk, co można wykonać po zalogowaniu się do panelu użytkownika (Login i hasło domyślne to user/user) na odpowiedniej podstronie. My - leniwi administratorzy nie mamy czasu, aby zaglądać tam co pół godziny, klikać jak szaleni, a ciągłe chodzenie i resetowanie modemu też jest nam nie w smak, dlatego też wolimy przygotować sobie trywialny i raczej brudny skrypt, który wykona nam tą operację za nas.

#!/bin/bash

modemip=${1}

u=${2}

p=${3}

address="http://${modemip}"

ua="Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

cookiefile="/tmp/${modemip}-cookie.txt"

sessionfile="/tmp/${modemip}-session.txt"

touch ${cookiefile}

touch ${sessionfile}

rm ${sessionfile}

rm ${cookiefile}

wget -quiet -cookies=on -keep-session-cookies -save-cookies=${cookiefile} -user ${u} -password=${p} -user-agent="${ua}" ${address} -O - >/dev/null

wget -quiet -cookies=on -load-cookies=${cookiefile} -keep-session-cookies -save-cookies=${cookiefile} -user ${u} -password=${p} -user-agent="${ua}" ${address}/statsifcreset.html -O - > /dev/null

wget -quiet -cookies=on -load-cookies=${cookiefile} -keep-session-cookies -save-cookies=${cookiefile} -user ${u} -password=${p} -user-agent="${ua}" ${address}/statswanreset.html -O - > /dev/null

wget -quiet -cookies=on -load-cookies=${cookiefile} -keep-session-cookies -save-cookies=${cookiefile} -user ${u} -password=${p} -user-agent="${ua}" ${address}/statsxtmreset.html -O - > /dev/null

wget -quiet -cookies=on -load-cookies=${cookiefile} -keep-session-cookies -save-cookies=${cookiefile} -user ${u} -password=${p} -user-agent="${ua}" ${address}/statsadslreset.html -O - > /dev/null

Teraz wystarczy drobny wpis do crona (jakiegoś komputera, mającego dostęp do panelu modemu):

*/10 * * * *root/usr/local/bin/comtrend-clearLog.sh IP_MODEMU user HASLO;

I już problem znika, a modem nie zjada więcej naszego bobu.

Rozwiązanie testowałem sobie przez 6 miesięcy i faktycznie moi użytkownicy przestali już narzekać, a telefon ucichł i nikt do słuchawki nie mówi: A nie kopnąłbyś routera, bo coś muli? Polecam.

• #2
  Autor: Krzysztof
  Treść: Czy na ten modem istnieje jakiś gotowy linux jak ddwrt czy openwrt?
  Dodano: 03.01.2021, 00:07:41
• #1
  Autor: Mariusz
  Treść: No tak, ale żeby wpisać skrypt trzeba mieć uprawnienia roota, czy tak?
  Bo z poziomu user/user nie da się chyba tego zrobić... Podobnie jak prozaiczna zmiana kanału Wi-Fi ze standardowej "1" też wymaga roota...
  Dodano: 04.09.2015, 17:26:41

Wiatr jedynie pośpiesznie przewiewa przez włosy porosłe w nieładzie, przerzedzone upływem czasu. Przenosi tylko zapachy teraźniejsze, informacje o przyszłości, pogodzie, która jeszcze się nie dokonała, a będzie lada chwila - jak zwykle zmienna, niepewna i nieposkromiona.

Dociekają nieliczni co z przyszłością będzie, co za pięć lat, dziesięć, za tydzień... Wyczytują splin blogowego bytu. Może i racje mają. Któż określić by mógł co jutro stanie się? Czy jeśli postanowię, że będę beztrosko szurał kijkiem po księżycowym regolicie już niebawem, ktokolwiek uwierzy? Czy to w ogóle ma jakiekolwiek znaczenie?

Przeszłość będzie zawsze lepsza od przyszłości. Zawsze! Dlaczego? Choćby i tylko dlatego, że ona już była. Ona już była, minęła, nie będzie jej tu drugi raz, nigdy więcej.

• #1
  Autor: Joanna
  Treść: A ja zacytuję "Piękne są chwile których jeszcze nie znamy..."
  Dodano: 04.06.2014, 12:53:13

Zanikam szybko, pytanie, na które każdy zna odpowiedź od tygodnia wciąż wali po małżowinie bezlitośnie, opadają już ręce, już nie chcę tego ciągnąć więcej, dość. Nagle słuchają wszyscy...

Całe życie w łańcuchu Markowa, całe to życie, które nie może być inne. Życie zdeterminowane wyborem narodzin, planowaniem lepszych dni, aż do śmierci i ogromnej pustki własnego psyche. Jeśli ktoś uważa, że życie to teatr wyborów - cóż, tak bardzo się myli, pierwsze skrzypce zawsze gra wybór pierwotny, z reguły nie Wasz.

Poczekam, aby ktoś pogonił mnie patykiem lub motyką, niczym łasego na cudze truskawki amatora grandowania. Na pozytywne pobudzenie z własnego wnętrza już raczej się nie doczekam chyba, chcę spać.

Załóżmy, że na serwerze, do którego będziemy się łączyć zainstalowany jest system operacyjny Linux z dostępnym już w systemie pakietem OpenVPN w wersji 2 (Dla uproszczenia, przyjmę, że jest to Debian). Konfigurację rozpoczniemy od wygenerowania odpowiednich certyfikatów i kluczy, następnie od utworzenia pliku konfiguracyjnego serwera, niezbędnych skryptów autoryzujących użytkownika oraz samych użytkowników poprzez utworzenie pliku konfiguracyjnego dla klientów.

Kopiujemy easy-rsa w dowolne miejsce - polecam, aby się nie pogubić, umieścić kopię w /etc/openvpn/easy-rsa/:

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

Następnie przechodzimy do tego katalogu i wykonujemy szereg poleceń:

cd /etc/openvpn/easy-rsa/

source ./vars

./clean-all

./build-ca (Tutaj wpisujemy kolejno informacje potrzebne do wystawienia certyfikatu, należy zapamiętać wartość "Common Name", dla uproszecznia polecam użyć: vpn-server)

./build-key-server WARTOŚĆ_COMMON_NAME (Tutaj wpisujemy potrzebne informacje do certyfikatu ("A challenge password" zostawiamy puste), a następnie wybieremy "y", aby podpisać certyfikat i potwierdzamy jeszcze na końcu "y". Jeżeli poprzednio, jako "Common Name" wpisano vpn-server, polecenie będzie miało postać: ./build-key-server vpn-server)

./build-dh

openvpn -genkey -secret ./keys/ta.key

Następnie tworzymy katalog /etc/openvpn/keys/ i kopiujemy do niego niezbędne pliki:
mkdir /etc/openvpn/keys

cd /etc/openvpn/keys

cp /etc/openvpn/easy-rsa/keys/ca.crt .

cp /etc/openvpn/easy-rsa/keys/COMMON_NAME.{key,crt} .

cp /etc/openvpn/easy-rsa/keys/dh1024.pem .

cp /etc/openvpn/easy-rsa/keys/ta.key .

Tworzymy plik konfiguracyjny serwera o nazwie vpn-server.conf w katalogu /etc/openvpn/:


local IP_ZEWNĘTRZNE_SERWERA

port 1194

proto udp

dev tap

tun-mtu 1500

server 10.119.202.0 255.255.255.0

ca /etc/openvpn/keys/ca.crt

cert /etc/openvpn/keys/COMMON_NAME.crt

key /etc/openvpn/keys/COMMON_NAME.key

dh /etc/openvpn/keys/dh1024.pem

tls-auth /etc/openvpn/keys/ta.key 0

cipher AES-256-CBC

persist-key

persist-tun

keepalive 5 60

reneg-sec 0

comp-lzo

user nobody

group nogroup

client-to-client

client-config-dir ccd

username-as-common-name

client-cert-not-required

auth-user-pass-verify /etc/openvpn/scripts/login.sh via-env

auth-nocache

max-clients 10

push "persist-key"

push "persist-tun"

ifconfig-pool-persist vpn-ipp.txt

# Przekierowanie całego ruchu przez VPN: push "redirect-gateway def1"

push "explicit-exit-notify 1"

script-security 3

status /var/log/vpn-server.status

log-append /var/log/vpn-openvpn.log

verb 0



Następnie tworzymy niezbędny skrypt autoryzujący użytkowników, o nazwie login.sh w katalogu /etc/openvpn/scripts/ (Tutaj autoryzacja jest oparta na pliku, ale nic nie stoi na przeszkodzie, aby użytkowników trzymać w bazie danych SQL czy w jakimś tam worku):

#!/bin/bash

hash=`echo -n $password|md5sum|awk {'print $1'}`

user_id=$(cat /etc/openvpn/vpn-passwd | grep "$username:$hash" | awk -F":" {'print $1'})

[ "$user_id" != '' ] && [ "$user_id" = "$username" ] && echo "user : $username" && echo 'authentication ok.' && exit 0 || echo 'authentication failed.'; exit 1


Należy jeszcze pamiętać, aby utworzyć jakiegoś użytkownika w pliku /etc/openvpn/vpn-passwd (format: user:md5(hasło)). Można się posłużyć trywialnym skryptem (o nazwie adduser.sh), aby ułatwić sobie pracę:

#!/bin/bash

echo -n "Login: "

read login

echo -n "Password: "

read pass

password=`echo -n "$pass" | md5sum | awk {'print $1'}`

echo $login:$password >> /etc/openvpn/vpn-passwd

echo "OK"

Aby utworzyć użytkownika należy wpisać w konsoli: /etc/openvpn/scripts/adduser.sh oraz podać login i hasło.

Powyższe skrypty zapisujemy w katalogu /etc/openvpn/scripts/ i pamiętamy, aby ustawić odpowiednie uprawnienia zarówno do katalogów jak i do pliku z hasłami:

chmod a+r /etc/openvpn/vpn-passwd

chmod o-r /etc/openvpn/keys -R

chmod a+r,a+x /etc/openvpn/scripts -R

Możemy przystąpić do konfiguracji po stronie klienta. Tworzymy plik tekstowy o następującej zawartości:

client

dev tap

proto udp

remote IP_ZEWNĘTRZNE_SERWERA 1194

nobind

persist-key

persist-tun

cipher AES-256-CBC

auth-user-pass

reneg-sec 14400

auth-nocache

comp-lzo

tun-mtu 1500

script-security 3

remote-cert-tls server

ca [inline]

tls-auth [inline] 1



ZAWARTOŚĆ PLIKU ca.crt





ZAWARTOŚĆ PLIKU ta.key



Jeżeli przerzucamy cały ruch przez nasz serwer VPN należy jeszcze pamiętać o odpowiedniej konfiguracji firewalla i przełączania pakietów:

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -i eth0 -o tap0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -s 110.119.202.0/24 -o eth0 -j ACCEPT

iptables -t nat -A POSTROUTING -s 10.119.202.0/24 ! -d 10.119.202.0/24 -o eth0 -j MASQUERADE

Możemy uruchomić już nasz serwer VPN (dla testów: openvpn -config /etc/openvpn/vpn-server.conf) i połączyć się wpisując openvpn -config vpn-server-client.ovpn. W przypadku, gdy wszystko okaże się działające możemy zautomatyzować start, zmieniając odpowiednie wpisy w pliku /etc/default/openvpn.

Jeżeli z jakichś powodów chcemy routować ruch tylko niektórym użytkownikom, należy w katalogu /etc/openvpn/ccd utworzyć plik Nazwa_użytkownika i zawrzeć w nim odpowiednie opcje konfiguracyjne: push "redirect-gateway def1", pamiętając, aby usunąć tą opcję w konfigu głównym. Dzięki dodatkowym plikom konfiguracyjnym można również powiedzieć, że klient może trasować pakiety do swojej lokalnej sieci lub w dowolną sieć. Możliwości jest pełno, zapraszam do eksperymentowania.

W załączeniu znajduje się gotowa konfiguracja z użytkownikiem guest i hasłem guest, powinna zadziałać w większości przypadków, ale zalecam do utworzenia własnej konfiguracji.

• #4
  Autor: Michał Sternadel
  Treść: Można spróbować użyć DNSMasq i podać mu w konfiguracji wygenerowany plik hosts na podstawie ipp.txt: cat /etc/openvpn/ipp.txt |awk -F',' {'print $2 " " $1'} >/etc/openvpn/hosts
  Uruchamiać przez: dnsmasq -H /etc/openvpn/hosts (...)
  Pozdrawiam.
  Dodano: 14.10.2016, 16:23:04
• #3
  Autor: Lukasz
  Treść: Masz jakiś sprawdzony sposób na rozwiązywanie nazw hostów wykorzystując do tego np plik ipp.txt ?
  Dodano: 09.10.2016, 12:34:56
• #2
  Autor: Maciej Ziemirski
  Treść: Po wpisaniu polecenia "iptables -A FORWARD -i eth0 -o tap0 -m state -state ESTABLISHED,RELATED -j ACCEPT" wywala komunikat ze niema takiego polecenia i i nie można się połączyć z serwerem. Debian 7 x64
  Dodano: 11.01.2015, 13:29:30
• #1
  Autor: ZigZag
  Treść: To działa! Dzięki.
  Dodano: 27.12.2013, 10:33:57