Поўнатунельны OpenVPN: дадайце выхад у інтэрнэт на баку сервера

Кліент праходзіць аўтэнтыфікацыю, атрымлівае адрас з пула і дасягае сэрвісаў на хасту VPN, але кожны публічны пункт прызначэння сканчаецца тайм-аўтам. Менавіта так выглядае тунель без выхаду, і так застаецца, пакуль не выканаюцца чатыры асобныя ўмовы. Кліент павінен прыняць маршрут па змаўчанні, сервер павінен перасылаць, міжсеткавы экран павінен дазволіць транзіт, а адказам патрэбны шлях назад у пул. Усе чатыры збоі маюць адзін сімптом, таму змяняйце па адным пункце за спробу і запісвайце вынік.

Праштурхніце маршрут па змаўчанні і праверце, што ўсталяваў кліент

Радок на баку сервера кароткі, і ён закранае толькі кліентаў, якія прымаюць праштурхнутыя опцыі. Форма def1 усталёўвае два паўмаршруты па змаўчанні замест выдалення існуючага маршруту, што захоўвае бягучае злучэнне жывым і адначасова перахоплівае кожны пункт прызначэння.

push "redirect-gateway def1"

Пасля перападключэння чытайце табліцу маршрутызацыі кліента, а не давярайце профілю. У Linux два запісы /1 з'яўляюцца побач з зыходным маршрутам па змаўчанні, а Windows паказвае тую ж пару як 0.0.0.0/1 і 128.0.0.0/1. Кліент, які ігнаруе праштурхнутыя опцыі або наладжаны адмаўляць іх, захоўвае стары маршрут па змаўчанні і ніколі не накіроўвае інтэрнэт-трафік у тунель. Вырашыце гэтае пытанне, перш чым нешта змяняць на серверы, бо ніякае правіла на баку сервера не кампенсуе.

Перасылка — гэта налада сервера, а не налада VPN

Прачытайце сцяг перасылкі, перш чым чапаць маршрутызацыю. Нуль там азначае, што ядро атрымлівае пакет кліента і адмаўляецца перадаць яго далей, што выглядае дакладна як блок міжсеткавага экрана з далёкага боку. Задайце значэнне праз каталог канфігурацыі сістэмы, каб яно перажыло перазагрузку.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Далей пераканайцеся, што сам хост мае працоўны маршрут да выхаду ў інтэрнэт. Запыт з абалонкі сервера даказвае, што вышэйшы шлях працаздольны, і нічога не кажа пра перасылку пакета кліента, таму стаўцеся да гэтага як да двух асобных тэстаў. Калі сервер не можа дасягнуць пункта прызначэння, ніякая колькасць налад перасылкі не дапаможа.

Дазвольце менавіта той транзіт, які маеце на ўвазе, і нічога больш

Перасланыя пакеты ідуць праз ланцуг forward; трафік, адрасаваны самому хасту VPN, ідзе праз ланцуг input. Гэта розныя рашэнні, і адкрыццё ланцуга input не дазваляе транзіт праз машыну. Блытаніна між імі — самая частая прычына, чаму міжсеткавы экран выглядае так, быццам дазваляе ўсё, а кліенты ўсё роўна атрымліваюць тайм-аўт.

Мінімальная палітыка прымае новыя злучэнні з пула да інтэрфейсу выхаду і прымае адказы, якія належаць усталяваным патокам. Размясціце яе ў тым уладальніку набораў правілаў, які выкарыстоўвае ваша дыстрыбуцыя, замест таго каб дадаваць дублікат правіла пры кожнай загрузцы; дублікаты назапашваюцца, і лічыльнікі губляюць сэнс.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Пераключэнне кожнага ланцуга на прыняцце прымушае тэст прайсці і знішчае сэнс існавання міжсеткавага экрана. Трымайцеся пула і інтэрфейсу выхаду, а не датычныя перасылкі пакіньце ў спакоі.

Дайце адказам куды ісці

Адрасы пула прыватныя, таму публічны сервер не можа даставіць адказ непасрэдна ім. Альбо хост VPN транслюе адрас крыніцы на выхадзе, альбо прылада вышэй трымае маршрут назад у пул.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Дадайце роўна адзін узровень трансляцыі. Другі NAT вышэй хавае першы і робіць абодва журналы амаль бескарыснымі, калі пазней нешта зламаецца. Калі маршрутызатар вышэй ужо вядзе пул назад, трансляцыя на хасту залішняя, і шлях вяртання тады залежыць ад канфігурацыі таго маршрутызатара, а не вашай.

Хмарныя інстансы дадаюць яшчэ адну браму, бо некаторыя платформы адкідаюць пакеты, адрас крыніцы якіх не належыць інстансу, пакуль гэтую праверку не паслабіць. Гэтая налада знаходзіцца па-за госцем, і яе лёгка забыць, калі лакальная тэставая машына працуе.

Давядзіце гэта з кліента, а не з абалонкі сервера

Пачніце з лікавага запыту IPv4, затым пошук па імені, затым праграма. ping даказвае перасылку і трансляцыю;ён нічога не даказвае пра развязанне імён, бо опцыі DNS дзейнічаюць толькі тады, калі іх усталёўвае інтэграцыя кліента.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Запісвайце змены і крок адкату па ходзе, каб палітыку выхаду можна было адкаціць адным дзеяннем, калі тэст праваліцца. Гэты рэцэпт ахоплівае толькі IPv4; інвентарызуйце IPv6 асобна, перш чым сцвярджаць, што разгортванне нясе ўвесь трафік.