Доброго вечера. В общем, пытаюсь создать конфиг для openVPN с максимальной производительностью и относительной беспалевностью. Арендовал VPS в Москве и в Лондоне, оба в минимальной конфигурации, 1 ядро, выдают по 2200 в Geekbench 4. Конфигурация сервера:

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
crl-verify crl.pem
tls-crypt ta.key

fast-io
auth SHA256
ncp-disable
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-GCM

#compress lz4-v2
#push "compress lz4-v2"

user nobody
group nogroup
persist-key
persist-tun

# Log a short status
status openvpn-status.log
log-append /etc/openvpn/logs/openvpn.log
verb 1

client
fast-io
script-security 2
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf

setenv opt tls-version-min 1.2 or-highest
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 185.220.33.172 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA256
cipher AES-256-GCM
setenv opt block-outside-dns
verb 3

Прием/отдача, пинг

• Без VPN: 56/56, 2-5
• EN VPN LZ4: 27/20, 81-100
• EN VPN no LZ4: 25/15-50, 81
• RU VPN LZ4: 54/55-70, 16
• RU VPN no LZ4: 51-54/54-55, 16

Сразу непонятно каким образом с LZ4 отдача с московским вышла больше, чем без VPN'а. Хотелось бы прояснить этот момент.

Дальше решил померить iperf'ом, правильно или нет поправьте. На сервере запускаю командой без VPN: iperf3 -s

с VPN: iperf3 -s --bind 10.8.0.1.

Клиент: iperf3 -с ip -N (с флагом -R или без)

Клиент через VPN: iperf -c 10.8.0.1 (с флагом -R или без)

Получил такие результаты. sender/reseiver, с флагом -R sender/reseiver

• EN without VPN: 53/50, 14/14
• EN with VPN no LZ4: 42/40, 8-10/8-10
• EN with VPN LZ4: 42/40, 8-10/8-10
• RU without VPN: 58/58, 58/58
• RU with VPN no LZ4: 56/56, 55/55
• RU with VPN LZ4: 56/56, 55/55

Сразу напрашивается вопрос, с чем связана такая низкая скорость в случае с Лондонским VPN? Такова ситуация с расстоянием или можно улучшить ситуацию? с LZ4 тоже стоит вопрос, стоит ли вообще использовать сжатие, ибо медиа файлы сжимать нет смысла, а все остальное и так сжимается gzip'ом. Лишь при высокой нагрузке будет отнимать ресурсы.

Далее встал вопрос с палевом VPN fingerprint, пробовал играться с параметром mssfix, но до конца так и не понял как это работает. Протестировал следующие случаи:

• Без mssfix 0 на сервере/клиенте, 1328 MTU с VPN fingerprint
• С mssfix 0 на сервере 1398 MTU с VPN fingerprint
• С mssfix 0 на сервере/клиенте 1500 MTU, при этом соединение с некоторыми сайтами становится нестабильным, нестабильная скорость отдачи.
• С mssfix 0 на сервере, mssfix на клиенте, 1398 MTU

Может кто подсказать что я тут нашаманил и почему все так? С этими VPN fingerprint вообще какая-то магия происходит, то они определяются, то нет.

И напоследок встал вопрос об DNS leak на линуксе и фикс двустороннего пинга. На линуксе пишут, что следует в конфиг клиента добавить строчки

up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Выдали нам учетные данные от VPN сервера.Поднял OpenSense 7.0(minimal), установил strongswan. структура сети такая

myComp--------->eth0 vpn-narhoz
192.168.1.141  |   192.168.1.34
               |
             eth0 gw1  eth1<------->internet<------>VPN server
         192.168.1.221 ExtIP                        91.214.174.2
                                                       |
                                                       |
                                                    10.0.4.83 

( читать дальше... )

ping от vpn-narhoz до машины 10.0.4.83 проходит, на myComp шлюзом прописан 192.168.1.221, прописал маршрут на myComp

ip route add 10.0.4.0/24 via 192.168.1.34

ip route show table 220
10.0.4.0/24 via 192.168.1.221 dev eth0 proto static src 192.168.20.101

VPN сервер выдает машине vpn-narhoz ip 192.168.20.101 Вывод команды strongswan statusall

Status of IKE charon daemon (strongSwan 5.6.1, Linux 3.10.0-693.21.1.el7.x86_64, x86_64):
  uptime: 108 seconds, since May 04 16:43:50 2018
  malloc: sbrk 1744896, mmap 0, used 575968, free 1168928
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon pkcs11 tpm aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
Listening IP addresses:
  192.168.1.34
Connections:
      narhoz:  %any...91.214.174.2  IKEv1 Aggressive
      narhoz:   local:  [192.168.1.34] uses pre-shared key authentication
      narhoz:   local:  uses XAuth authentication: any with XAuth identity 'akamakov'
      narhoz:   remote: uses pre-shared key authentication
      narhoz:   child:  dynamic === 10.0.4.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
      narhoz[1]: ESTABLISHED 108 seconds ago, 192.168.1.34[192.168.1.34]...91.214.174.2[91.214.174.2]
      narhoz[1]: IKEv1 SPIs: abad95d00452658f_i* f237b2a90ddf6b5f_r, pre-shared key+XAuth reauthentication in 2 hours
      narhoz[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
      narhoz{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ce27afea_i a2de341f_o
      narhoz{1}:  AES_CBC_128/HMAC_SHA1_96/MODP_1536, 168 bytes_i (2 pkts, 101s ago), 168 bytes_o (2 pkts, 101s ago), rekeying in 41 minutes
      narhoz{1}:   192.168.20.101/32 === 10.0.4.0/24

PS: Сори за «распашонку», но «cut» «/cut» не скрывает под спойлер код

Etherpad позволяет редактировать документы совместно в режиме реального времени в вашем браузере.
Пишите статьи, пресс-релизы, списки дел вместе с друзьями, однокурсниками и знакомыми, все работают над одним документом одновременно.

Etherpad поддерживает плагины, с помощью которых можно настроить сессию для ваших нужд. Каждая сессия предоставляет доступ ко всем данным через документированные API и поддерживает импорт/экспорт документов широко известных форматов.

Вам необязательно настраивать свой сервер и устанавливать Etherpad для его использования. Достаточно выбрать одну из публичных сессий, созданными людьми из всего мира. Или же можете настроить свою собственную сессию, следуя инструкциям.

Список изменений в версии 1.4:

• Отключение инструментов через settings.json.
• Движок внутренней статистики/метрики.
• API функция Pad копировать/переместить.
• Метод getAttributeOnSelection.
• Новые блоки eejs.
• Ace afterEditHook
• preProcessDomLine разрешает обрабатывать сначала атрибуты Domline.

Скриншот

Github

>>> Официальный сайт