Мастковы VPN-хотспот: які маршрут па змаўчанні выкарыстоўвае тэлефон?
Маршрут па змаўчанні на Pi — не шлюз тэлефона. Раздзяліце два рашэнні, трымайце uplink па-за мастом і праверце lease да тунэля.
Тэлефон у вашым мастковым хотспоце атрымлівае адрас і шлюз недзе, і гэта не маршрут па змаўчанні на Pi. Змена маршруту па змаўчанні на Pi змяняе, куды Pi адпраўляе свой уласны трафік. Тэлефон працягвае выкарыстоўваць шлюз, пра які яму сказалі, і калі гэты шлюз знаходзіцца ў аддаленай LAN, яго кадры проста перасякаюць мост. Два спажыўцы, два рашэнні. Іх раздзяленне тлумачыць большасць паведамленняў пра хотспот без інтэрнэту, калі сам Pi ў парадку.
Дзве прылады, два розныя рашэнні пра шлюз
У Pi ёсць уласны IP-стэк і ўласны маршрут па змаўчанні. У тэлефона ёсць уласны IP-стэк і ўласны маршрут па змаўчанні.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
Гэтая табліца — уся мадэль. Шлюз тэлефона — гэта адрас у аддаленай LAN, і яго кадры перадаюцца на ўзроўні 2 да гэтага маршрутызатара. Маршрут па змаўчанні на Pi датычыцца ўласнага знешняга транспарту Pi, які павінен дасягнуць VPN-піра праз дарожны uplink.
Мост перасылае кадры, ён не маршрутызуе пакеты
Мост Linux перасылае Ethernet-кадры па MAC-адрасе прызначэння, і гэта ўсё, што ён робіць паміж сваімі партамі. Кадр тэлефона, адрасаваны MAC-адрасу аддаленага маршрутызатара, камутуецца на порт TAP і перасякае тунэль, не закранаючы табліцу маршрутызацыі Pi. Таму зламаны маршрут па змаўчанні на Pi можа пакінуць тэлефон працаздольным, і таму правільны не можа выправіць тэлефон, якому далі няправільны шлюз.
TAP нясе Ethernet-кадры і можа быць портам моста. TUN нясе IP-пакеты і не можа. Калі ваш дызайн замяніў адно на другое, мост не з'яўляецца мостам, і ўсё астатняе тут не прымяняецца.
Вызначце, хто выдае lease тэлефона
Параметр DHCP 3 — гэта параметр маршрутызатара, і ён паведамляе кліенту, які шлюз выкарыстоўваць для яго падсеткі. Калі DHCP-сервер аддаленай LAN — адзіны размеркавальнік, тэлефон атрымлівае аддалены шлюз, і дызайн узгоджаны. Калі нешта іншае на баку падарожжа адказвае першым, тэлефон атрымлівае лакальны шлюз, яго інтэрнэт-трафік ідзе праз дарожны uplink, і яго трафік у аддаленую LAN не мае шляху наогул.
Запусціце адзін размеркавальнік для гэтага broadcast-дамена і запішыце, што ён выдае.
Pi — асобны выпадак, нават калі бярэ адрас з таго ж lease. Свядома вырашыце, ці павінен ён усталёўваць маршруты, якія прапануе lease, бо імпартаваны аддалены маршрут па змаўчанні можа зацягнуць уласны VPN-транспарт Pi у тунэль, які ён спрабуе ўтрымаць жывым. У systemd-networkd гэта рашэнне — UseRoutes= у раздзеле DHCP; у dhclient гэта параметр routers у спісе запытаў.
Трымайце uplink па-за мастковай LAN
Інтэрфейс, які нясе знешняе VPN-злучэнне Pi, не павінен станавіцца портам моста. Калі ён ім стане, шыфраваны транспарт камутуецца ў пашыраную LAN, і тунэль пачынае несці свае ўласныя знешнія пакеты, што адмаўляе такім чынам, які выглядае як страта пакетаў, а не як пятля. Трымайце магчымасць AP і падтрымку моста таксама яўнымі. Бесправадны інтэрфейс у рэжыме station звычайна не можа быць портам моста, бо ў загалоўку 802.11 няма месца для другога MAC-адраса, патрэбнага мосту.
Вызначце пашыраны broadcast-дамен, адзін план адрасоў і фільтраванне кадраў, якое вы сапраўды хочаце. Дазвол VPN-слухачу на Pi не дае кожнаму мастковаму кліенту доступ да службаў кіравання Pi. Гэта асобныя правілы, і стаўленне да іх як да аднаго — гэта тое, як хотспот ціха становіцца адчыненымі дзвярыма.
Праверце чатыры рэчы асобна, калі яно зламалася
Калі тэлефон не можа дасягнуць аддаленай LAN, чатыры назіранні раздзяляюць прычыны. Выканайце іх у гэтым парадку і спыніцеся на першым, што не ўдалося.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpПачніце з lease: ці трымае тэлефон адрас і шлюз у аддаленай падсетцы? Затым паглядзіце на мост і пераканайцеся, што порт AP і порт TAP абодва перасылаюць. Затым прачытайце табліцу суседзяў, бо невырашаны запіс для аддаленага маршрутызатара азначае, што кадры сыходзяць, а нішто не адказвае. Нарэшце назірайце за кадрамі на мосце, пакуль тэлефон пінгуе, што скажа вам, ці знаходзіцца няспраўнасць увогуле ніжэй за IP.
Запішыце, якая прылада валодае кожным маршрутам па змаўчанні, калі скончыце. Адзін радок дакументацыі ператварае лакальны супраць аддаленага egress у свядомае рашэнне кліента, і спасылку на мост варта трымаць побач.