VPN Ручник



  • Здравствуйте. Помогите кто чем может. Имеется PFSense 2.0.1  (amd64), с жутким тормозом внутри VPN подключения. На данный момент испытывал на PPTP и OpenVPN подключениях как внутри сети так и снаружи через WAN интерфейсы. Т.е. будь то прокачка ресурсов самбы, загрузка файлов по FTP или просто шныряние по web морде, скорость не поднимается выше 3 мбит, при том что оба wan имеют 100 мбит, ну и lan также. Загрузка процессора не поднимается выше 15%. Та же самба без VPN отлично бегает через все интерфейсы. Вторую неделю бьюсь, уже не знаю в какую сторону копать.



  • Версию на x86 смените.



  • Ого. Это ж всё переставлять прийдёться…
    Сейчас вот заметил что всё таки загрузка через лан внутри vpn ИЗ pfsense идёт на всю ширину канала, а вот закачка данных НА него ограничивается 2-3 мбит. И ещё: пинг пакетом в 1472 байт составляет 1мс, а пакет в 1473 байт доходит уже за 120мс. Изменение значения MTU на стороне клиента не меняют картину.



  • Ого. Это ж всё переставлять прийдёться…

    Слить конфиг - установить pf - залить конфиг.



  • Установить пакеты, залить конфиг.



  • Да меня больше установка самбы напрягает. Просто хочется быть уверенным что смена версии на x86 даст результат. С этим действительно кто-то сталкивался? Почему такие выводы про x64?



  • С пакетами точно будут напряги.



  • Переустановил таки на x86. Вообще ничего не изменилось. Пинг пакетами 1472 байт внутри тонеля бежит меньше 1 мс, 1473-1491 байт не возвращаются вообще, а пакеты больше 1492 байт идут 20-210 мс.

    Обнаружилась ещё одна особенность. Если во время копирования файла НА сервер запустить копирование ИЗ него, то скорость заливки резко увеличивается, а пинги значительно уменьшаются, да и тормоза пропадают.



  • Частично разобрался с тормозами. OpenVPN у меня был поднят через TCP, PPTP он итак через TCP порты работает, вот TCP поверх TCP и дает такие глюки. Перевел OpenVPN в режим работы через UDP и всё заколосилось. Теперь вопрос немного не в тему. Никак не могу открыть UDP порты на WAN интерфейсе. Т.е. если переназначаю UDP порт на комп в локалке, то он открывается и норм работает, а как открываю порт для openvpn сервера, который стоит на pfsense так с него ответа извне нет, и ничем подключиться не получается, соостветсвенно и L2TP, из-за невозможности открыть UDP порт, тоже не могу поднять.



  • @uastalker:

    Частично разобрался с тормозами. OpenVPN у меня был поднят через TCP, PPTP он итак через TCP порты работает, вот TCP поверх TCP и дает такие глюки. Перевел OpenVPN в режим работы через UDP и всё заколосилось. Теперь вопрос немного не в тему. Никак не могу открыть UDP порты на WAN интерфейсе. Т.е. если переназначаю UDP порт на комп в локалке, то он открывается и норм работает, а как открываю порт для openvpn сервера, который стоит на pfsense так с него ответа извне нет, и ничем подключиться не получается, соостветсвенно и L2TP, из-за невозможности открыть UDP порт, тоже не могу поднять.

    А чем вы проверяете открытость UDP-порта? Обычным телнетом? Не сработает. Используйте Nmap.



  • В успешном открытии порта на комп в локалке убеждаюсь с помощью мула (eMule), как только пробрасываю в pfsense порт, мул сразу это показывает. А то что на pfsense порты не открываются ясно потому что ни OpenVPN ни L2TP извне не коннектятся (точнее OpenVPN коннектится но только в TCP режиме). Может я что-то недопонимаю?



  • @uastalker:

    В успешном открытии порта на комп в локалке убеждаюсь с помощью мула (eMule), как только пробрасываю в pfsense порт, мул сразу это показывает. А то что на pfsense порты не открываются ясно потому что ни OpenVPN ни L2TP извне не коннектятся (точнее OpenVPN коннектится но только в TCP режиме). Может я что-то недопонимаю?

    А в правилах fw на wan у вас появилось разрешение на открытие порта для openvpn?



  • Да, всё есть. И для OpenVPN, L2TP и для PPTP. Но через wan работает только последний.



  • Чудеса, но сегодня всё само собой заработало. Даже пфсенс не перегружал. В очередной раз пытался достучаться извне к OpenVPN через UDP и он подключился. И бегает хорошо.


Log in to reply