Hindi nagkikita ang mga kliyente ng OpenVPN: subnet o net30?

Dalawang walang kaugnayang sira ang nagdudulot ng parehong reklamo. Sa una, hindi naaabot ng isang kliyente ang isa pa kahit sa address ng tunnel, dahil wala sa isang subnet ang mga address o hindi ipinapasa ng server ang trapik sa pagitan ng mga peer. Sa pangalawa, gumagana ang ping pero nananatiling walang laman ang listahan ng device ng app, dahil umaasa ang pagtuklas sa broadcast na hindi kayang dalhin ng tunnel sa layer 3. Isang ping ang naghihiwalay sa kanila, at ang ayos ng bawat isa ay hindi talaga kahawig ng ayos ng isa.

Hinahati ng isang ping ang problema sa dalawa

Mula sa isang kliyente, i-ping ang address ng tunnel ng kabilang kliyente, hindi ang pangalan at hindi ang address nito sa LAN. Kung mabigo iyon, ang pagpapasa o pag-address ang problema at walang kaugnayan ang pagtuklas hanggang sa maayos iyon. Kung magtagumpay, gumagana na ang pagpapasa at ang kulang ay broadcast o paglutas ng pangalan.

ip addr show tun0

Basahin muna ang interface ng kliyente bago ang lahat, dahil pinapangalanan ng netmask ang topology. Ang /24 o ibang subnet mask ay nangangahulugang pinagsasaluhang pool; ang /30 na may peer address ay ang lumang point-to-point na layout, kung saan eksaktong isang kapitbahay lang ang bawat kliyente, ang server.

net30 kumpara sa subnet, binabasa mula sa panig ng kliyente

Sa net30, namimigay ang server ng maliit na bloke bawat kliyente, kaya walang ruta patungo sa address ng tunnel ng ibang kliyente maliban kung ipapasa ito ng server. Sa subnet, isang network ang buong pool, maaaring kausapin ng bawat kliyente ang bawat isa, at ipinapasa ng server sa pagitan nila. Kaya maaaring magmukhang malusog ang isang configuration ng server habang nabibigo ang ping sa pagitan ng mga peer: walang sira, wala lang sa isang network ang mga kliyente. Nakikita ng kliyente ang gumaganang link at isang peer address na hindi sumasagot, na parang firewall kung basahin pero layout ng pag-address pala.

Ang pagpapalit ng direktiba ay pag-edit sa panig ng server at restart, at ito ay para sa susunod na koneksyon hindi sa mga session na nakabukas na. Ikonekta muli ang mga kliyente bago hatulan ang pagbabago. Kung muling binubuo ng aparato ang configuration mula sa web interface, itala ang direktiba, file at petsa, at gawin ang pag-edit sa pamamagitan ng interface kapag mayroon, dahil papawiin ng muling pagbuo ang manual na edit sa susunod na pag-save.

Ang client-to-client ay hiwalay na pintuan

Kahit sa loob ng isang subnet, itinatapon ng server ang mga packet na nagmumula sa isang kliyente at naka-address sa iba maliban kung nakatakda ang client-to-client. Ginagawa ng keyword na iyon ang server na tagapagpasa ng trapik sa pagitan ng mga peer sa halip na endpoint na tumatanggap lang. Ito ang ikalawang kondisyon na nakakalimutan ng mga tao pagkatapos ayusin ang topology.

Hindi ito umaabot sa broadcast. Ipinapasa ng setting ang unicast sa pagitan ng mga kliyente; hindi nito ginagawang pinagsasaluhang segment ang tunnel, at wala sa dami nito ang maghahatid ng multicast discovery query sa bawat peer.

TUN kumpara sa TAP, at ano ang kayang dalhin ng bawat isa

Ang pag-bridge ng aparatong tap papasok sa LAN ay naglalagay ng malalayong kliyente sa broadcast domain ng opisina, na ganap na lumulutas sa pagtuklas. Ang halaga ay ang mga platform na hindi nagpapatupad ng TAP, isang bridge na dapat umiral sa server, at isang failure domain kung saan umaabot sa bawat malayong laptop ang broadcast storm sa kable ng opisina.

Para sa dalawa o tatlong workstation na kailangan ng paglutas ng pangalan, mas mura ang tala sa hosts o unicast address kaysa sa bridge. Gumamit ng TAP kapag ang protokol na hindi mo kayang palitan ay umaasa sa pagtuklas sa layer 2, at hindi bago iyon.

Mga kliyente sa parehong subnet na walang bridge

Ang pagbibigay ng address mula sa hanay ng LAN ay hindi naglalagay ng kliyente sa kable. Nagru-route ang server sa pagitan ng tunnel at Ethernet, kaya humihinto ang ARP para sa address na iyon sa interface ng server at hindi kailanman nalalaman ng natitirang LAN kung saan ito nakatira.

ip neigh add proxy 10.50.1.250 dev eth0

Isinasara ng Proxy ARP ang puwang na iyon sa pamamagitan ng pagsagot ng server sa ngalan ng kliyente. Para sa isang hanay, pinamamahalaan ng parpd ang mga entry habang dumarating at umaalis ang mga kliyente, samantalang sinasagot ng sysctl net.ipv4.conf.eth0.proxy_arp=1 ang lahat ng niru-route sa ibang lugar, na sapat ang lawak upang lumikha ng sarili nitong sorpresa sa abalang segment.

Anumang ruta ang piliin, alisin ang NAT sa pagitan ng tunnel at kable. Itinatago ng MASQUERADE rule ang eksaktong tanong sa pag-address na sinusubukan mong sagutin. Iniwan din nito sa susunod na tao ang topology na hindi niya kayang isipin mula sa panig ng kliyente.

Bago baguhin ang anuman, kunin ang isang pagtatangka sa server gamit ang tcpdump -ni tun0 at kumpirmahin kung dumarating talaga ang packet ng peer. Ang pagdating at pagkatapon ay tumuturo sa client-to-client; ang hindi pagdating kailanman ay tumuturo sa topology o routing. Ang manwal ng OpenVPN 2.6 ay nagdodokumento ng dalawang keyword at ng default na topology, na sulit itapat sa iyong bersyon bago kopyahin ang isang linya mula sa post sa forum.

• Ipinapakita ng tun interface ang pool mask sa halip na pares ng peer /30.
• Nagtitagumpay ang direktang ping sa kabilang tunnel address bago mo subukan ang pagtuklas.
• May client-to-client sa configuration ng server tuwing kailangang magpalitan ng packet ang mga peer.
• Pangalanan ang protokol ng pagtuklas na sinusubukan mo sa halip na sabihing nabibigo ang app.
• Gamitin ang TAP kung sinusuportahan lang ito ng bawat client platform sa grupo.
• Panatilihing labas ng daan sa pagitan ng tunnel at LAN ang NAT kapag mahalaga ang maabot sa parehong subnet.