OpenVPN клиентите не се виждат един друг: подмрежа или net30?
Клиентите стигат до сървъра, но не един до друг. Разделете повредата с един ping, после изберете топология подмрежа, client-to-client или мостов TAP сегмент.
Две несвързани повреди дават една и съща оплакване. При първата един клиент не стига до друг дори по адреса на тунела, защото адресите не са в една подмрежа или сървърът не препраща трафик между партньори. При втората ping работи, а списъкът с устройства в приложението остава празен, защото откриването разчита на broadcast, който тунел от 3-то ниво не може да носи. Един ping ги разделя, а поправката за всяка от тях не прилича на поправката за другата.
Един ping разделя проблема на две
От един клиент пуснете ping към адреса на тунела на другия клиент, а не към името и не към LAN адреса му. Ако се провали, проблемът е в препращането или адресирането и откриването е без значение, докато не се поправи. Ако успее, препращането вече работи и остатъкът е broadcast или разрешаване на имена.
ip addr show tun0Прочетете интерфейса на клиента преди всичко друго, защото мрежовата маска казва топологията. /24 или друга маска на подмрежа означава споделен пул; /30 с адрес на партньор означава старата схема точка-точка, при която всеки клиент има точно един съсед — сървъра.
net30 срещу подмрежа, прочетено от страната на клиента
| 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 сървърът раздава малък блок на всеки клиент, затова маршрут до адреса на тунела на друг клиент не съществува, освен ако сървърът не го препрати. С подмрежа целият пул е една мрежа, всеки клиент може да адресира всеки друг и сървърът препраща между тях. Затова една конфигурация на сървъра може да изглежда здрава, докато ping между партньорите се проваля: нищо не е счупено, просто клиентите не са в една мрежа. Клиентът вижда работеща връзка и адрес на партньор, който не отговаря, което изглежда като защитна стена, но всъщност е схема на адресиране.
Смяната на директивата е редакция от страната на сървъра плюс рестарт и важи за следващата връзка, а не за вече установени сесии. Свържете клиентите наново, преди да съдите за промяната. Ако устройство пресъздава конфигурацията от уеб интерфейс, запишете директивата, файла и датата и правете редакцията през интерфейса, когато има такъв, защото пресъздаването ще презапише ръчна редакция при следващото запазване.
client-to-client е отделна врата
Дори в една подмрежа сървърът изхвърля пакети, дошли от един клиент и адресирани до друг, освен ако client-to-client не е зададен. Тази ключова дума превръща сървъра в препращач на трафик между партньори, вместо в крайна точка, която само го приема. Това е второто условие, което хората пропускат, след като оправят топологията.
Това не се разпростира върху broadcast. Настройката препраща unicast между клиентите; тя не прави тунела споделен сегмент и никакво количество от нея няма да достави multicast заявка за откриване до всеки партньор.
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 поставя отдалечените клиенти в broadcast домейна на офиса, което решава откриването напълно. Цената е платформите, които не реализират TAP, мост, който трябва да съществува на сървъра, и домейн на отказ, в който broadcast буря по офисния кабел стига до всеки отдалечен лаптоп.
За две или три работни станции, които се нуждаят от разрешаване на имена, запис в hosts или unicast адрес е много по-евтин от мост. Прибягвайте до 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, когато достижимостта в една подмрежа е важна.