Чи достатньо Raspberry Pi для офісного VPN? Визначте роботу

Raspberry Pi із чотирма гігабайтами — це опис машини, а не офісна вимога. Він може добре обслуговувати кількох віддалених користувачів, а може впасти вже першого пообіддя, коли хтось копіює великий файл через тунель. Число пам'яті не може сказати, що з цього станеться. Перетворення покупки на приймальний тест замінює цю невизначеність результатом, який ви можете захистити.

Перетворіть питання на приймальний тест

Приймальний тест називає роботу, умови та поріг проходження до того, як прибуде будь-яке обладнання. Для VPN-шлюзу робота — це набір одночасних дій, а умови — задіяні шляхи й служби. Поріг проходження — це те, що користувач назвав би придатним до роботи, а не те, що повідомляє мірило. Без усіх трьох число не має жодного твердження.

Напишіть тест так, щоб його могла провести інша людина. Саме це обмеження прибирає більшість розпливчастих критеріїв, через які такі рішення тягнуться тижнями. Воно також робить результат порівнюваним, коли надходить наступний огляд.

Результат може виправдати Raspberry Pi, інший пристрій або керовану службу. Усі три — законні відповіді на те саме питання. Між ними вибирає тест, а специфікація — ні.

Запишіть роботу, а не кількість людей

Розділяйте дії, а не рахуйте користувачів. Відкриття вебзастосунку, копіювання великого файлу та запуск інтерактивного термінала створюють дуже різне навантаження на той самий шлюз. Позначте, які з них перекриваються протягом звичайної години, бо саме перекриття перетворює три легкі задачі на одну складну.

Зафіксуйте й напрямок. Віддалені користувачі, які завантажують з офісного файлового сервера, споживають висхідний канал офісу, і швидке клієнтське з'єднання не компенсує вузький шлях на іншому кінці.

Якщо тунель несе й звичайний перегляд, уключіть цей трафік до тесту. Лише приватний доступ занижує те, що побачить шлюз, коли офіс почне використовувати його для всього.

Виміряйте зібраний пристрій

Перевіряйте ту версію, протокол і автентифікацію, які збираєтеся розгорнути. Запишіть, який шлях обробки пакетів активний, замість того щоб позичати мірило з іншої збірки. Пропускна здатність залежить від цього шляху, тому спостереження з іншого шляху описує іншу систему. Сенс у тому, щоб виміряти свою конфігурацію, а не найкращу з доступних.

Уключіть служби, які ділитимуть плату. Фільтрація DNS, моніторинг або сховище конкурують за той самий процесор і пам'ять, а шлюз, виміряний окремо, — не той, який ви будете експлуатувати.

Стежте за активністю процесора, тиском на пам'ять, помилками інтерфейсів і часом завершення під час тривалої роботи. Тримайте шифрування й керування доступом увімкненими весь час, бо число, отримане без них, описує службу, яку ніхто не затвердив.

Визначте бюджет простою до обладнання

Один недорогий шлюз — розумний вибір, коли його простій прийнятний, а відновлення просте. Запишіть припустимий час недоступності та хто може відновити конфігурацію, замінити носій і відкликати втраченого клієнта. Саме ці операції визначають, скільки насправді триває простій. Жодна з них не вказана в специфікації.

Якщо адміністратор потрапляє на шлюз лише через той самий тунель, передбачте незалежний шлях відновлення. Запасна плата, конфігурацію та ключі якої неможливо відновити і якою ніхто не володіє, — не план відновлення.

Називайте людину, а не команду. Відновлення, що залежить від групи, — це відновлення, яке чекає, поки група буде доступною. Ім'я — це ще й те, що робить план перевірним.

Виберіть найменшу систему, яка проходить

Виберіть найменшу підтримувану систему, яка проходить оголошені вимоги із запасом. Більше пам'яті допомагає, коли пам'ять — це обмеження, і нічого не дає вже насиченому шляху. Запас має бути заявленою часткою, а не прикметником. Тоді й наступне оновлення матиме критерій.

Запишіть навантаження, результат і дату поруч із впровадженням. Тоді наступне питання про ємність починається з доказів, а не зі специфікації. Цей запис — різниця між рішенням і здогадом.