OpenVPN клијенти не виде једни друге: подмрежа или net30?
Клијенти стижу до сервера, али не једни до других. Раздвојите квар једним ping-ом, затим изаберите топологију подмреже, client-to-client или мостни TAP сегмент.
Две неповезане грешке дају исту жалбу. У првој један клијент не стиже до другог чак ни по адреси тунела, јер адресе нису у истој подмрежи или сервер не прослеђује саобраћај између партнера. У другој ping ради, а листа уређаја у апликацији остаје празна, јер откривање зависи од broadcast-а који тунел 3. нивоа не може да носи. Један 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-а када је важна доступност у истој подмрежи.