OpenVPN Access Server. Перенаправлення вхідних запитів клієнтам мережі через NAT »Crossroads

OpenVPN Access Server - програмний пакет, що відрізняється від OpenVPN простотою настройки через зручний веб інтерфейс і тим, що готовий до роботи практично відразу після установки. Про встановлення та поверхневої налаштуванні я вже писала раніше . Зараз же я хочу приділити увагу портам.
Ряд служб, запущених на стороні користувача, нерідко вимагають наявності відкритих портів для коректної роботи. Такі програми, як клієнти, ігри з режимом мультиплеєра, де ініціатор сесії так само виступає в ролі сервера, до якого приєднуються інші гравці, і інші - всі вони вимагають відкриття певних портів на комп'ютері користувача для вхідних з'єднань.
У «повсякденності» перенаправленням запитів на порти займається роутер або модем, за допомогою. Але в моєму випадку, наприклад, між мною і точкою виходу в Інтернет в цілому три a і два програмних фаервола. Іншими словами, що входять сполуки - проблема. Вирішується ця проблема підняттям тунелю між ПК і точкою виходу. В такому випадку трафік мине всі ці вузли одним шифрованих потоком і «розбирається» тільки на моєму комп'ютері і на стороні точки виходу, де піднята OpenVPN. Так само публічні мережі і безліч будинкових мереж нерідко блокують всі вхідні з'єднання, з тієї простої причини, що всі клієнти мережі виходять в Інтернет з одного зовнішнього IP, при цьому технології типу UPnP цими мережами не підтримуються. Плюс до всього, публічні Wi-Fi мережі просто не безпечні. Іншими словами, використання VPN може бути виправдане багатьма факторами: від параної і реальної цензури всередині країни, до просто бажання контролювати свій трафік особисто, чи не публікуючи весь розклад провайдеру і іншим зацікавленим особам.
Отже, налаштовуємо OpenVPN Access Server. В панелі управління, в секції «VPN Mode» налаштовуємо режим роботи нашого сервера. OpenVPN Access Server може працювати в двох режимах. «Layer 2» (ethernet bridging) і «Layer 3» (routing / NAT). Обидва режими мають як плюси, так і мінуси. В контексті даної ситуації, кращим може бути варіант «Layer 2». Він простіший з мінімумом налаштувань, при цьому всім клієнтам мережі будуть присвоюватися локальні IP адреси реально існуючої локальної мережі на фізичному інтерфейсі. Якщо зовнішній інтерфейс у нас eth0, то локальний як правило eth1. Тобто сервер підключений до локальної мережі з діапазоном IP адрес, наприклад 10.10.1.0/24. У цій ситуації клієнтам мережі будуть присвоюватися адреси типу 10.10.1.2, 10.10.1.3, 10.10.1.4 і так далі. У цьому випадку ніяких додаткових налаштувань не потрібно і UPnP буде перенаправляти вхідні з'єднання на клієнтські комп'ютери. Безсумнівним мінусом подібного режиму є те, що все це буде працювати переважно на Windows. Тобто клієнтський комп'ютер повинен бути під управлінням Windows. Ви не зможете підключитися до такої мережі з планшета на Android і інших пристроїв. Головним же мінусом є той факт, що на стороні сервера повинна бути ця локальна мережа як така, при цьому в ній повинна працювати технологія UPnP, а адреси повинні призначатися сервером. Якщо все це вам не підходить, то залишається варіант з NAT (режим «Layer 3»). Його ми і розглянемо докладніше.
У розділі «VPN Settings» особливі настройки не потрібні. У моєму випадку настройки виглядають як на скріншоті, але настройки «Static IP Address Network» не мають відношення до нашого завдання. У моєму випадку це діапазон локальних IP, які можуть бути призначені певним клієнтам як статичні. У цьому немає необхідності і клієнтам можуть призначаються IP адреси в діапазоні 172.27.232.0/20 (що є діапазоном за замовчуванням для OpenVPN Access Server), при цьому все буде працювати.
Переходимо в розділ «User Permissions» і налаштовуємо права окремо взятого користувача. Відкривати порти ми будемо за допомогою.
Демілітаризована зона в OpenVPN Access Server реалізована досить грамотно, в порівнянні з рядом побутових роутерів, де на машину в DMZ перенаправляються всі вхідні запити до всіх портів, при цьому IP адреса такої машини повинен бути статичним. В Access Server все інакше. Запити перенаправляються нема на IP, а на клієнта (IP клієнта при цьому може бути динамічним) і не всі вхідні запити, а запити, адресовані на певні порти, за певними протоколами. Синтаксис наступний: внешній_ip_сервера: протокол / порт. Наприклад, p2p клієнт «Ace Stream HD» на моєму ПК використовує порт 48621 по tcp і по udp. Стало бути, буде два записи подібного виду:
ххх.ххх.хх.хх: tcp / 48621 ххх.ххх.хх.хх: udp / 48621
Для платформи Steam - ххх.ххх.хх.хх: udp / 27000-27050 і ххх.ххх.хх.хх: tcp / 27015. І так далі.
З Steam варто проявити обережність. VPN у них асоціюється виключно зі спробою обходу регіональних обмежень і цінової політики, при якій в зв'язку зі стрімким падінням рубля, на приклад, ігри в рублевої зони стоять в середньому в два-три рази дешевше, ніж в доларовій зоні. А в доларовій зоні гри дешевше, ніж в зоні євро. Найбільше не пощастило Аргентині, де за еквівалент в 80 доларів США можна отримати те ж саме, що в самих США буде коштувати доларів 50, а в Росії рублів 800-900. Так чи інакше, але при спробі це обійти і в разі, якщо вас зловлять, ваш аккаунт гарантовано виявиться в довічному лазні, з усіма наслідками, що випливають. Однак, у світлі російської влади, зміниться або цінова політика Valve в Росії, або їх відношення до VPN, або і те й інше. Перший варіант більш імовірний. Хоча подібне траплялося, мабуть, з усіма міжнародними сервісами, представленими в Росії, але поки ніхто дверима не грюкнув. І з приводу DMZ на сайті підтримки написано, що система працювати не буде. Але у випадку з OpenVPN Access Server все як би працює. Принаймні я не стикалася з проблемами з'єднання і Steam працює як задумано, начебто. Детальніше про портах, використовуваних в Steam, можна ознайомитися на.
В іншому ж, рішення, засноване на DMZ в OpenVPN Access Server виглядає практично ідеальним. Мінусом є той факт, що ви не можете відкрити один і той же порт для декількох клієнтів. Навіть якщо онлайн знаходиться тільки один з них. Якщо ви відкрили порти Steam для певного клієнта, то тільки він і зможе їх використовувати.
У налаштуванні «iptables» ж на боці сервера необхідності немає, навіть якщо ви використовуєте будь-яку сторонню утиліту для управління фаєрволом, типу «UFW». Access Server сам прописує всі необхідні правила iptables «на льоту». Що означає, що правило активно лише тоді, коли клієнт онлайн. Якщо ви відкрили ряд портів для певного клієнта, то «додзвонитися» до цих портів можна лише тоді, коли клієнт підключений до мережі. Якщо клієнт офлайн, то і порти закриті. Даний факт є безсумнівним плюсом в плані безпеки.
Для перевірки портів на стороні клієнтського ПК можна використовувати програму « PortForward Network Utilities ». У триальной версії вона довічно безкоштовна, хоча і навантажена рекламою, при цьому урізана. Але для перевірки портів її цілком достатньо.
Як видно з скріншоту, у мене відкритий udp порт 27025. При цьому, як я сказала раніше, між мною і виходом в Інтернет три NATa і два фаервола, якщо вважати iptables на стороні Access Сервера і BitDefender на ПК. Якщо я відключуся від Access Server, то порт буде закритий. І не важливо з якого боку його прозванивать.

___
Tatyana K.