Кліенты OpenVPN не бачаць адзін аднаго: subnet ці net30?
Кліенты дасягаюць сервера, але не адзін аднаго. Падзяліце збой адным ping, затым выберыце тапалогію subnet, client-to-client або мастоўваны сегмент TAP.
Дзве незвязаныя няспраўнасці даюць адну і тую ж скаргу. У першай адзін кліент не дасягае іншага нават па адрасе тунеля, бо адрасы не ў адной падсетцы або сервер не перасылае трафік паміж вузламі. У другой ping працуе, а спіс прылад у праграме застаецца пустым, бо выяўленне абапіраецца на шырокавяшчанне, якое тунель 3-га ўзроўню несці не можа. Адзін ping раздзяляе іх, і выпраўленне для кожнага зусім не падобнае да выпраўлення для іншага.
Адзін ping дзеліць праблему на дзве
З аднаго кліента пінганіце адрас тунеля іншага кліента, а не яго імя і не яго адрас у LAN. Калі гэта не ўдаецца, праблема ў перасылцы або адрасацыі, і выяўленне не мае значэння, пакуль гэта не выпраўлена. Калі ўдаецца, перасылка ўжо працуе, а рэштка праблемы — шырокавяшчанне або развязанне імёнаў.
ip addr show tun0Чытайце інтэрфейс кліента перш за ўсё, бо маска падсеткі называе тапалогію. /24 або іншая маска падсеткі азначае агульны пул; /30 з адрасам суседа азначае старую схему пункт-пункт, дзе ў кожнага кліента роўна адзін сусед — сервер.
net30 супраць subnet, чытаецца з боку кліента
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
З net30 сервер выдае невялікі блок на кожнага кліента, таму маршрут да адраса тунеля іншага кліента не існуе, пакуль сервер яго не перашле. З subnet увесь пул — адна сетка, кожны кліент можа звярнуцца да кожнага, і сервер перасылае паміж імі. Вось чаму адна канфігурацыя сервера можа выглядаць здаровай, пакуль ping паміж вузламі не ўдаецца: нішто не зламана, проста кліенты не ў адной сетцы. Кліент бачыць працоўнае злучэнне і адрас суседа, які не адказвае, што выглядае як фаервол, але насамрэч гэта схема адрасацыі.
Пераключэнне дырэктывы — гэта праўка на баку сервера плюс перазапуск, і яна дзейнічае для наступнага злучэння, а не для ўжо ўсталяваных сеансаў. Перападключыце кліентаў, перш чым ацэньваць змену. Калі прылада перагенеруе канфігурацыю з вэб-інтэрфейсу, запішыце дырэктыву, файл і дату і рабіце праўку праз інтэрфейс, калі ён ёсць, бо перазбор перазапіша ручную праўку пры наступным захаванні.
client-to-client — асобная брама
Нават унутры адной падсеткі сервер адкідвае пакеты, якія прыйшлі ад аднаго кліента і адрасаваныя іншаму, калі не ўключаны client-to-client. Гэтае ключавое слова робіць сервер перасылальнікам трафіку паміж вузламі, а не канчатковым пунктам, які толькі прымае яго. Гэта другая ўмова, якую людзі прапускаюць пасля выпраўлення тапалогіі.
Гэта не пашыраецца на шырокавяшчанне. Настаўленне перасылае аднаадрасныя пакеты паміж кліентамі; яно не робіць тунель агульным сегментам, і ніякая яго колькасць не даставіць запыт выяўлення множнай рассылкі кожнаму суседу.
TUN супраць TAP, і што кожны можа несці
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
Маставанне прылады tap у LAN змяшчае аддаленых кліентаў у шырокавяшчальны дамен офіса, што цалкам вырашае выяўленне. Кошт — платформы, якія не рэалізуюць TAP, мост, які павінен існаваць на серверы, і дамен адмовы, дзе шырокавяшчальная бура на офісным кабелі дасягае кожнага аддаленага ноўтбука.
Для двух-трох працоўных станцый, якім патрэбна развязанне імёнаў, запіс hosts або аднаадрасны адрас значна таннейшы за мост. Бярыцеся за TAP, калі пратакол, які вы не можаце замяніць, залежыць ад выяўлення на 2-м узроўні, і не раней.
Кліенты той жа падсеткі без моста
Прызначэнне адраса з дыяпазону LAN не ставіць кліента на кабель. Сервер маршрутызуе паміж тунелем і Ethernet, таму ARP для гэтага адраса спыняецца на інтэрфейсе сервера, і астатняя LAN ніколі не даведаецца, дзе ён знаходзіцца.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP зачыняе гэтую прагаліну: сервер адказвае за кліента. Для дыяпазону parpd кіруе запісамі, пакуль кліенты прыходзяць і сыходзяць, а sysctl net.ipv4.conf.eth0.proxy_arp=1 адказвае за ўсё, што маршрутызуецца ў іншае месца, і гэта даволі шырока, каб стварыць свае нечаканасці на занятым сегменце.
Які б шлях вы ні абралі, прыбярыце NAT паміж тунелем і кабелем. Правіла MASQUERADE хавае менавіта тое пытанне адрасацыі, на якое вы спрабуеце адказаць. Яно таксама пакідае наступнаму чалавеку тапалогію, пра якую ён не зможа разважаць з боку кліента.
Перш чым нешта змяніць, злавіце адну спробу на серверы з tcpdump -ni tun0 і пацвердзіце, ці пакет вузла прыходзіць наогул. Прыходзіць і адкідваецца — гэта client-to-client; не прыходзіць зусім — гэта тапалогія або маршрутызацыя. Кіраўніцтва OpenVPN 2.6 апісвае абодва ключавыя словы і стандартную тапалогію, і гэта варта зверыць са сваёй версіяй, перш чым капіяваць радок з допісу на форуме.
- Інтэрфейс tun паказвае маску пула, а не пару суседа /30.
- Прамы ping на іншы адрас тунеля ўдаецца да праверкі выяўлення.
- Канфігурацыя сервера ўтрымлівае
client-to-client, калі вузлы павінны абменьвацца пакетамі. - Назвіце пратакол выяўлення, які вы правяраеце, замест таго каб казаць, што праграма збаіць.
- Выкарыстоўвайце TAP, толькі калі ўсе кліенцкія платформы ў групе яго падтрымліваюць.
- Трымайце NAT па-за шляхам паміж тунелем і LAN, калі важная дасяжнасць унутры адной падсеткі.