Абагульце адно VPN-злучэнне на ўсе прылады ў вашай LAN

Адзін ноўтбук трымае тунель, астатні дом хоча такі ж доступ, і першая спроба — накіраваць усё на злучаную машыну. Яна правальваецца з прычын, якія не маюць нічога агульнага з VPN: хаст-атрымальнік павінен пераслаць пакет, перапісаць яго крыніцу і пераканацца, што адказы знойдуць шлях назад. Прапусціце хоць адно з трох — і злучаны ноўтбук працягвае працаваць, пакуль кожная іншая прылада атрымлівае тайм-аўт. Рашэнне — гэта праект маршрутызацыі, а не налада кліента.

Чаму накіраванне прылад на хаст не працуе

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

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

Уключыце перасылку і трансляцыю на хасце

Дзве змены на злучаным хасце закрываюць першыя дзве часткі: уключыце перасылку IPv4 і транслюйце трафік LAN на інтэрфейс тунеля.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Захавайце значэнне sysctl у файле ў /etc/sysctl.d і пераправерце правіла MASQUERADE пасля перазапуску, бо інтэрфейсы фаервола могуць ачышчаць уласныя ланцугі. На Windows функцыя абагульвання выконвае абодва крокі, але яна таксама пераадрасоўвае адаптар LAN на фіксаваную падсетку і ачышчае яго шлюз, што ламае статычную адрасацыю і перасылку портаў. Аднавіце шлях роўтара да хаста на яго новым адрасе, перш чым рабіць выснову, што абагульванне не ўдалося. Затым назірайце, як лічыльнікі правілаў растуць, пакуль другая прылада адпраўляе трафік.

Дайце LAN шлях, які перажыве перазапускі

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

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Накіраванне шлюза па змаўчанні кліента на хаст адпраўляе ўвесь яго трафік праз хаст, уключаючы лакальны друк і абагульванне файлаў, таму староннія рэчы спыняюцца, калі хаст засынае. Даданне пэўнага маршруту на роўтары для выдаленага прэфікса вузейшае: толькі пункты прызначэння за тунелем ідуць на злучаную машыну, а астатняя LAN працягвае працаваць. Падсеткі вышэй — прыклады, таму падстаўце свае дыяпазоны LAN і тунеля. У любым выпадку праверце з другой прылады пры ўключаным, а затым выключаным тунелі.

Сачыце за MTU, перш чым вінаваціць тунель

Тунелі паменшваюць даступны памер пакета, і другая прылада пра гэта не ведае. Вялікія перадачы і TLS-узгадненні затыкаюцца, пакуль малыя запыты паспяховыя.

ping -M do -s 1400 10.8.0.5

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

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