Я установил OpenVPN с помощью эти инструкции с целью подключения к внешнему миру с помощью IP-адреса AWS, а не IP-адреса, назначенного моим интернет-провайдером.
Соединение успешно. Когда я пингую (от клиента), например, google.com при подключении к VPN, я получаю
Pinging google.com [172.217.9.174] with 32 bytes of data:
Reply from 172.217.9.174: bytes=32 time=122ms TTL=45
Reply from 172.217.9.174: bytes=32 time=262ms TTL=45
Reply from 172.217.9.174: bytes=32 time=119ms TTL=45
Reply from 172.217.9.174: bytes=32 time=121ms TTL=45
по сравнению с несколько более быстрыми пингами, когда не используется VPN-соединение
Pinging google.com [172.217.6.174] with 32 bytes of data:
Reply from 172.217.6.174: bytes=32 time=84ms TTL=52
Reply from 172.217.6.174: bytes=32 time=85ms TTL=52
Reply from 172.217.6.174: bytes=32 time=89ms TTL=52
Reply from 172.217.6.174: bytes=32 time=82ms TTL=52
Однако, когда я пытаюсь загрузить веб-сайт (например, cnn.com) в браузере на клиенте, загрузка почти всегда прерывается.
Я пробовал добавить
sndbuf 0
rcvbuf 0
в конфигурацию OpenVPN как на клиенте, так и на сервере, результат тот же.
Клиент - Windows 10, а сервер - Ubuntu 16.04, работающий на экземпляре AWS Nano. top не показывает значительной нагрузки на сервер при попытке подключения.
Скорость подключения клиента составляет 300 Мбит / с вниз / 30 Мбит / с вверх.
Что еще я могу попытаться достичь приемлемой скорости через OpenVPN?
Я не могу комментировать из-за отсутствия у меня сейчас репутации.
Во-первых, в какой зоне доступности вы настроили свой экземпляр EC2 в AWS? Я предполагаю, что один из самых близких к вам? Вы используете VPC в AWS? Оба они вводят множество других переменных, которые могут способствовать снижению производительности сети.
Я подозреваю, что t2.nano недостаточно мощен для настройки OpenVPN. В инструкциях, которым вы следовали, конкретно говорится, что используйте t2.micro. По моему опыту, у t2.nano смехотворно низкая производительность сети, хотя t2.micro не намного лучше.
Таким образом, я предлагаю повысить уровень экземпляра до t2.micro или даже t2.medium (временно), чтобы исключить производительность сети в области AWS.
Вот дальнейшее чтение о производительности сети EC2
Вот дальнейшее чтение о производительности виртуальных ЦП / памяти EC2
Учитывая, что вышеизложенное не решает проблему, мое следующее подозрение может быть связано с раздельное туннелирование. Ваш клиент вытесняет весь трафик через ваш туннель? Вы можете проверить это, выполнив либо route PRINT или tracert google.com. При использовании route то вы должны увидеть, что весь трафик направляется в туннель. При использовании tracert вариант, то вы должны увидеть, что ваш второй или третий переход проходит через вашу VPN.
Учитывая, что один из двух приведенных выше вариантов показывает маршрутизацию трафика через VPN, вы знаете, что разделенное туннелирование отключено. Однако это не означает, что DNS будет работать должным образом. Попробуйте выполнить nslookup google.com 8.8.8.8. Это заставляет общедоступные DNS-серверы Google (8.8.8.8) выполнять разрешение доменного имени вместо вашей локальной сети или DNS внутри AWS. Теперь проблема nslookup google.com 192.168.1.1, заменяя 192.168.1.1 с IP-адресом вашего локального шлюза (обычно вашего маршрутизатора). Если это работает, то последний вариант - подключиться к экземпляру EC2 по SSH и просто nslookup google.com.
Если после выполнения всего вышеперечисленного вы по-прежнему испытываете эту проблему, ответьте на любые дальнейшие выводы, которые вы сделали при выполнении вышеуказанных действий.