Мостов hotspot с VPN: кой маршрут по подразбиране използва телефонът?
Маршрутът по подразбиране на Pi не е шлюзът на телефона. Разделете двете решения, дръжте uplink извън моста и тествайте lease преди тунела.
Телефонът в мостовия ви hotspot получава адреса и шлюза си отнякъде и това не е маршрутът по подразбиране на Pi. Промяната на маршрута по подразбиране на Pi променя къде Pi изпраща собствения си трафик. Телефонът продължава да използва шлюза, за който са му казали, и когато този шлюз е в отдалечената LAN, кадрите му просто преминават през моста. Два консуматора, две решения. Разделянето им обяснява повечето съобщения за hotspot без интернет, докато самият 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. Това са отделни правила и третирането им като едно е начинът, по който един hotspot тихо става отворена врата.
Тествайте четирите неща поотделно, когато се счупи
Когато телефонът не може да достигне отдалечената 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 в съзнателно решение на клиента и препратката към моста си заслужава да стои до него.