rPman

сетевой инженер занимается сетями, настройкой оборудования, проектирование сетей и т.п. (в вырожденных случаях он же и провода тянет).
системный администратор настраивает операционную систему и программы

в некоторых случаях системный администратор может выполнять задачи сетевого инженера, но когда сеть крупная, удобнее и логичнее выделить на это отдельного человека

По уму любой openwrt совместимый, если на него поставить эту прошивку то позволит например через это (первое что нагуглил)

Все зависит от того, какие именно технологии тебе нужны.

При наличии ssh сервера (удаленный сервер, в локальной корпоративной сети, куда тебе нужен доступ), то у тебя автоматически (это отключается администратором но по умолчанию обычно есть) есть возможность подключить на выбор:

* socks прокси сервер (локальный, любая ОС), достаточно подключиться к ssh серверу с ключом -D1080 и у тебя появится локальный socks5 прокси без атворизации (будет localhost:1080)
Это все что нужно для работы прокси, никаких настроек (максимум озаботиться об автоматическом запуске без пароля). Но прокси требует наличие поддержки в приложениях (браузеры поддерживают все).

* tap или tun туннель (не windows машины) с помощью ключа -w 0:0 (цифры тут это номер tap или tun устройства, создаваемого локально и на удаленной машине
для создания tap туннеля нужно добавить опцию -o Tunnel=ethernet в этом случае сетевое устройство будет полноценным ethernet подключением, его можно добавить в сетевой мост со всеми вытекающими от сюда плюсами.
ssh только создает tap/tun сетевое устройство, но дальнейшую его настройку (ip адрес, настройка nat) нужно делать уже по тем правилам как у тебя организована сеть.
Например на удаленном сервере можно организовать сетевой мост, в него поместить аппаратный сетевой адаптер и при ssh подключении добавлять созданный им tun/tap интерфейс, в этом случае туннель подключится к удаленной (корпоративной) локальной сети как машина в этой сети и ей будет выдан ip адрес согласно настроек этой сети
То же самое можно делать и на клиенте, собственно нет никакой разницы как именно было организовано ssh подключение (у меня был конфиг когда ssh сервер из удаленной сети, к которой мне нужен доступ но на нем не было выделенного открытого порта, только доступ в интернет за nat) подключался к моей домашней машине (ssh сервер), подключив таким образом мою домашнюю машину в удаленную сеть, при этом в локальной домашней сети я сделал то же самое, поместил ее сетевой адаптер в сетевой мост и добавил в него tun от ssh, отключив dhcp в моей локальной сети, я получил единую локальную сеть, управляемую удаленно (т.е. ip адреса выдавались удаленной сетью, а так же настройки шлюза, т.е. интернет работал удаленный), в довесок я прописывал на машинах таблицу маршрутизации route add ... указав какие подсети нужно отправлять через мой локальный шлюз а не удаленный.

p.s. ssh туннель полнофункциональный, удобный, универсальный... но это tcp подключение (т.е. при проблемах в сети будут большие лаги, ping может легко стать 5-секундным) , а еще российские провайдеры периодически (полагаю не 'со зла' а как последствия 'ковровых бомбардировок' других протоколов) замедляют именно ssh подключения

Исторически в linux есть socat, инструмент поднятия туннеля любого типа через любой тип соединения, сам он по себе не шифрует подключения но можно нагородить конструкцию любой сложности другими утилитвми, попробуй его

про curl и lynx уже ответили, добавлю от себя вариант с созданием скриншота

chromium --headless --disable-gpu --hide-scrollbars --window-size=1280,800 --screenshot=myscreenshot.png http://localhost

тут же можно замерить время загрузки, правда алгоритм определения окончания загрузки может неверно распознать формируемые на javascript страницы (но он все еще работает в большинстве случаев)