Вчера я развернул обычную установку OpenVPN на Debian Squeeze / Amazon EC2. VPN-сервер находится в Сингапуре, и я подключаюсь к нему с материкового Китая. Позже, после некоторых тестов, мне пришлось задуматься над исправлением OpenVPN патчем «Scrambled», чтобы включить скремблирование пакетов, чтобы я не блокировал мои UPD-пакеты Великим брандмауэром.
Я скомпилировал сегодня из источника, указанный патч + OpenVPN, на экземпляре M3 (точно так же, как вчера), и теперь соединение стабильно, но у меня ужасная задержка. вчера у меня было 80 мс при пинге интерфейса tun сервера, а сегодня у меня стабильный жир 270 мс.
Возможно ли, что скремблирование пакетов увеличивает накладные расходы и, таким образом, приводит к ужасному увеличению задержки? Или вы думаете, что может быть больше проблем? Конфигурация точно такая же, как та, которую я сделал вчера для сервера.
port 443
proto udp
dev tun
scramble obfuscate guardian
ca /etc/openvpn/ca.crt
cert /etc/openvpn/elmer.crt
key /etc/openvpn/elmer.key
tls-auth /etc/openvpn/ta.key 0
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
cipher DES-EDE3-CBC
comp-lzo
tun-mtu 1300
persist-key
persist-tun
user www-data
group www-data
status openvpn-status.log
verb 3
КОНФИГУРАЦИЯ КЛИЕНТА:
client
dev tun
scramble obfuscate guardian
proto udp
remote xx.xx.xx.xx 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert beijing.crt
key beijing.key
tls-auth ta.key 1
ns-cert-type server
cipher DES-EDE3-CBC
comp-lzo
verb 3
fast-io
script-security 2
Патч скремблирования не добавляет накладных расходов на связь (размер пакета не меняется) и незначительных накладных расходов ЦП. Ваши проблемы вызваны непредсказуемым характером подключения Китая к внешнему миру. Советую переместить vpn в другое место. Япония, Корея, Гонконг и Тайвань должны работать намного лучше.