OpenVPN-klientoj ne vidas unu la alian: subnet aŭ net30?
Klientoj atingas la servilon sed ne unu la alian. Apartigu la difekton per unu ping, poste elektu subnet-topologion, client-to-client aŭ pontitan TAP-segmenton.
Du sendependaj difektoj kaŭzas la saman plendon. En la unua, unu kliento ne atingas alian eĉ per la tunela adreso, ĉar la adresoj ne estas en unu subneto aŭ la servilo ne plusendas trafikon inter samtavolanoj. En la dua, ping funkcias kaj la aparatlisto de la aplikaĵo restas malplena, ĉar malkovro dependas de dissendo, kiun tunelo de tavolo 3 ne povas porti. Unu ping apartigas ilin, kaj la riparo por ĉiu el ili tute ne similas al la riparo por la alia.
Unu ping dividas la problemon en du
De unu kliento, pingu la tunelan adreson de la alia kliento, ne ĝian nomon kaj ne ĝian LAN-adreson. Se tio malsukcesas, plusendado aŭ adresado estas la problemo kaj malkovro estas nerelevanta ĝis ĝi estos riparita. Se ĝi sukcesas, plusendado jam funkcias kaj la restanta manko estas dissendo aŭ nomrezolucio.
ip addr show tun0Legu la klientan interfacon antaŭ ĉio alia, ĉar la retmasko nomas la topologion. /24 aŭ alia subreta masko signifas komunan naĝejon; /30 kun samtavolana adreso signifas la pli malnovan punkt-al-punkta aranĝon, kie ĉiu kliento havas precize unu najbaron, la servilon.
net30 kontraŭ subnet, legite de la klienta flanko
| 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 |
Kun net30 la servilo disdonas malgrandan blokon por ĉiu kliento, do itinero al la tunela adreso de alia kliento ne ekzistas krom se la servilo plusendas ĝin. Kun subnet la tuta naĝejo estas unu reto, ĉiu kliento povas adresi ĉiun alian, kaj la servilo plusendas inter ili. Tial unu servila agordo povas ŝajni sana dum ping inter samtavolanoj malsukcesas: nenio estas rompita, la klientoj simple ne estas en unu reto. La kliento vidas funkciantan ligilon kaj samtavolan adreson, kiu ne respondas, kio legiĝas kiel fajroŝirmilo sed estas adresa aranĝo.
Ŝalti la direktivon estas redakto ĉe la servila flanko plus restartigo, kaj ĝi validas por la sekva konekto prefere ol por sesioj jam malfermitaj. Rekonektu la klientojn antaŭ ol juĝi la ŝanĝon. Se aparato regeneras la agordon el reta interfaco, notu la direktivon, la dosieron kaj la daton, kaj faru la redakton tra la interfaco kiam ĝi ekzistas, ĉar rekonstruo anstataŭigos manan redakton ĉe la sekva konservo.
client-to-client estas aparta pordego
Eĉ ene de unu subneto la servilo forĵetas pakaĵojn, kiuj venas de unu kliento kaj estas adresitaj al alia, krom se client-to-client estas agordita. Tiu ŝlosilvorto igas la servilon plusendilo por samtavolana trafiko anstataŭ finpunkto, kiu nur akceptas ĝin. Ĝi estas la dua kondiĉo, kiun homoj maltrafas post ripari la topologion.
Ĝi ne etendiĝas al dissendo. La agordo plusendas unuopaĵon inter klientoj; ĝi ne igas la tunelon komuna segmento, kaj neniu kvanto de ĝi liveros pludissendan malkovran peton al ĉiu samtavolano.
TUN kontraŭ TAP, kaj kion ĉiu povas porti
| 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 |
Ponti tap-aparaton en la LAN metos foraĵajn klientojn en la oficejan dissendan domajnon, kio tute solvas malkovron. La prezo estas la platformoj, kiuj ne realigas TAP, ponto, kiu devas ekzisti sur la servilo, kaj difekta domajno, kie dissenda ŝtormo sur la oficeja kablo atingas ĉiun foran tekkomputilon.
Por du aŭ tri laborstacioj bezonantaj nomrezolucion, hosts-enskribo aŭ unuopa adreso estas multe pli malmultekosta ol ponto. Prefere uzu TAP kiam protokolo, kiun vi ne povas anstataŭigi, dependas de malkovro de tavolo 2, kaj ne antaŭe.
Klientoj de la sama subneto sen ponto
Doni adreson el la LAN-gamo ne metas la klienton sur la kablon. La servilo rutas inter tunelo kaj Ethernet, do ARP por tiu adreso haltas ĉe la servila interfaco kaj la resto de la LAN neniam ekscias, kie ĝi loĝas.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP fermas tiun mankon per tio, ke la servilo respondas nome de la kliento. Por gamo, parpd administras la enskribojn dum klientoj venas kaj foriras, dum la sysctl net.ipv4.conf.eth0.proxy_arp=1 respondas pri ĉio ruta aliloken, kio estas sufiĉe larĝa por krei proprajn surprizojn sur okupata segmento.
Kian ajn vojon vi elektos, forigu NAT inter la tunelo kaj la kablo. Regulo MASQUERADE kaŝas precize la adresan demandon, kiun vi provas respondi. Ĝi ankaŭ lasas al la sekva persono topologion, pri kiu ĝi ne povas rezonis de la klienta flanko.
Antaŭ ol ŝanĝi ion ajn, kaptu unu provon sur la servilo per tcpdump -ni tun0 kaj certigu, ĉu la samtavolana pakaĵo entute alvenas. Alveni kaj esti forĵetita montras al client-to-client; neniam alveni montras al topologio aŭ rutado. La manlibro de OpenVPN 2.6 dokumentas ambaŭ ŝlosilvortojn kaj la implicitan topologion, kio indas kompari kun via versio antaŭ kopii linion el forumafiŝo.
- La tun-interfaco montras naĝejan maskon anstataŭ /30-samtavolan paron.
- Rekta ping al la alia tunela adreso sukcesas antaŭ ol vi testas malkovron.
- La servila agordo inkluzivas
client-to-clientkiam ajn samtavolanoj devas interŝanĝi pakaĵojn. - Nomu la malkovran protokolon, kiun vi testas, anstataŭ diri, ke la aplikaĵo malsukcesas.
- Uzu TAP nur se ĉiu klienta platformo en la grupo subtenas ĝin.
- Tenu NAT for de la vojo inter tunelo kaj LAN kiam atingeblo ene de la sama subneto gravas.