hostapd і OpenVPN на адным Raspberry Pi: каму належыць маршрут па змаўчанні?

Тэлефоны падключаюцца да кропкі доступу, атрымліваюць адрас і потым не дасягаюць нічога, як толькі ўзнімаецца тунель. hostapd у такім стане звычайна здаровы, і OpenVPN таксама; ламаецца маршрут па змаўчанні, які альбо ніколі не існаваў на мосце, альбо быў заменены тунелем без пакідання шляху да самога VPN-сервера. Гэты дапаможнік вяртае гэты маршрут на сваё месца і даказвае вынік з кліента, а не з Raspberry Pi. Кожны крок можна адкаціць, і нішто тут не змяняе канфігурацыю тунеля, пакуль вы не ведаеце, які трафік хочаце ўнутры яго.

Пералічыце інтэрфейсы, перш чым нешта змяняць

Звыклая схема змяшчае бесправадное радыё і драцяны порт унутры br0, запускае hostapd супраць моста і выдае арандаванні з dnsmasq, а кліент OpenVPN стварае tun0. Тады тры асобныя патрабаванні выглядаюць як адно: кліентам кропкі доступу патрэбен Raspberry Pi як іх шлюз, Raspberry Pi патрэбен маршрут у інтэрнэт, каб дасягнуць свайго сервера, а мосту патрэбен адрас шлюза, які гэтыя кліенты могуць выкарыстоўваць.

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

ip -br addr
ip route show
ip link show master br0
bridge link show

Калі br0 мае адрас, але не мае маршруту па змаўчанні, кліенты дасягаюць Raspberry Pi і нічога за ім. Калі маршрут па змаўчанні паказвае на tun0, пакуль тунель не працуе, Raspberry Pi зусім не мае працоўнага шляху, і сімптом кліента выглядае абсалютна таксама. Абодва выпадкі выглядаюць аднолькава з тэлефона, таму табліцу маршрутаў трэба чытаць непасрэдна.

Дайце мосту маршрут па змаўчанні, які належыць яму

Raspberry Pi OS часта пакідае мост без маршруту па змаўчанні, калі мост узнік пасля запісу файла інтэрфейса. Блок належыць у /etc/dhcpcd.conf, і ён павінен называць вышэйшы маршрутызатар, а не Raspberry Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

У гэтым прыкладзе 192.168.50.1 — гэта існуючы маршрутызатар, а 192.168.50.2 — адрас моста Raspberry Pi у той жа падсетцы, таму падстаўце свой план замест капіравання лікаў. Члены моста таксама не павінны запытваць маршрутызатары, інакш Raspberry Pi атрымае канкуруючыя маршруты па змаўчанні, пераможца якіх залежыць ад метрыкі і часу, а не ад намеру.

Пасля systemctl restart dhcpcd ip route show default павінен паказаць br0 адзін раз і без дубліката з драцянога порта. Пацвердзіце пошук, а не табліцу, бо састарэлы запіс можа стаяць побач з пераможным: ip -4 route get 203.0.113.10 павінен назваць br0. Гэты адрас паходзіць з дыяпазону дакументацыі TEST-NET-3, таму ён не можа сутыкнуцца з рэальным серверам, пакуль вы гэта чытаеце.

Не дазваляйце тунелю выкрадаць шлях да свайго сервера

Кліент OpenVPN, які прымае redirect-gateway, забірае маршрут па змаўчанні і накіроўвае яго ў тунель. Гэта правільна, калі кожны кліент кропкі доступу павінен выкарыстоўваць VPN, і няправільна, калі павінны толькі некаторыя прызначэнні. У любым выпадку ўласнае злучэнне Raspberry Pi з серверам не павінна ісці ўнутры тунеля, які ён яшчэ будуе. OpenVPN дадае маршрут да хоста праз зыходны шлюз, калі ён перанакіроўвае маршрут па змаўчанні, і гэта менавіта тое паводзіны, якое трымае транспарт жывым; калі гэтага маршруту няма, тунель развальваецца, як толькі ўстанаўліваецца.

Хуткае параўнанне гэтага транспартнага шляху да і пасля падлучэння вартае дзесяці секунд. ip -4 route get 203.0.113.10 павінен назваць прыладу ніжняга ўзроўню ў абодвух станах, змяняецца толькі метрыка. Калі ён называе tun0 пасля ўзняцця тунеля, маршрут да хоста ніколі не быў усталяваны, і наступнае перападлучэнне не ўдасца.

Калі праз тунель павінны ісці толькі выбраныя прэфіксы, выкарыстоўвайце route-nopull і дадайце патрэбныя маршруты ўручную або адпраўце вузейшы набор з сервера. Мост захоўвае маршрут па змаўчанні ў такой схеме, і DNS становіцца наступным рашэннем: перанакіраванне dnsmasq на хатні рэзалвер мае сэнс толькі для імёнаў, якія сапраўды там жывуць.

Вызначце гісторыю з перанакіраваннем і NAT

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

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

Правіла NAT — гэта кароткі шлях, які працуе, калі сервер не прымае прэфікс кропкі доступу, цаной таго, што кожны кліент выглядае як тунельны адрас Raspberry Pi ў журналах далёкага боку. Маршрутызацыя прэфікса без NAT захоўвае адрасы бачнымі і залежыць ад зваротнага маршруту для 192.168.50.0/24 на хатнім баку.

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

Праверце з кліента, затым акуратна адкаціце

Тэстуйце ў гэтым парадку з тэлефона або ноўтбука на кропцы доступу: арандаванне з dnsmasq, ping да адраса моста, затым прызначэнне на далёкім баку тунеля. Кожны крок ізалюе адзін узровень замест таго, каб даваць адзіную бескарысную памылку.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Затым пацвердзіце, што Raspberry Pi па-ранейшаму мае ўласны выхад: ip route get 203.0.113.10 павінен назваць прыладу ніжняга ўзроўню, а ping -c 3 -I br0 203.0.113.10 павінен адказаць, калі сервер дазваляе ICMP. Калі першыя два крокі кліента праходзяць, а трэці не ўдаецца, няспраўнасць у перанакіраванні або NAT. Калі другі крок не ўдаецца, мост або DHCP яшчэ не завершаны.

Адкат — гэта адно рэдагаванне файла і дзве каманды: выдаліце блок, перазапусціце dhcpcd і заменіце маршрут па змаўчанні яўна на ip route replace default via 192.168.50.1 dev br0. Зрабіце гэта да закрыцця акна абслугоўвання, а не пасля, бо Raspberry Pi, які страціў маршрут па змаўчанні, недасягальны з сеткі, якую вы выкарыстоўвалі б для яго рамонту.