Nid yw cleientiaid OpenVPN yn gweld ei gilydd: is-rwydwaith neu net30?

Mae dau nam annibynnol yn rhoi'r un gŵyn. Yn y cyntaf, ni all un cleient gyrraedd y llall hyd yn oed drwy gyfeiriad y tiwnel, oherwydd nad yw'r cyfeiriadau mewn un is-rwydwaith neu nad yw'r gweinydd yn anfon traffig rhwng cymheiriaid. Yn yr ail, mae ping yn gweithio ac mae rhestr dyfeisiau'r ap yn aros yn wag, oherwydd bod darganfod yn dibynnu ar ddarllediad na all tiwnel haen-3 ei gynnal. Mae un ping yn eu gwahanu, ac nid yw'r atgyweiriad ar gyfer y naill yn debyg o gwbl i'r atgyweiriad ar gyfer y llall.

Mae un ping yn hollti'r broblem yn ddwy

O un cleient, pingiwch gyfeiriad tiwnel y cleient arall, nid ei enw ac nid ei gyfeiriad LAN. Os yw hynny'n methu, anfon neu gyfeirio yw'r broblem ac mae darganfod yn amherthnasol nes iddi gael ei thrwsio. Os yw'n llwyddo, mae anfon eisoes yn gweithio a'r bwlch sy'n weddill yw darllediad neu ddatrys enwau.

ip addr show tun0

Darllenwch ryngwyneb y cleient cyn unrhyw beth arall, oherwydd mai'r mwgwd rhwydwaith sy'n enwi'r dopoleg. Mae /24 neu fwgwd is-rwydwaith arall yn golygu pwll a rennir; mae /30 gyda chyfeiriad cymar yn golygu'r cynllun pwynt-i-bwynt hŷn, lle mae gan bob cleient un cymydog yn union, y gweinydd.

net30 yn erbyn is-rwydwaith, wedi'i ddarllen o ochr y cleient

Gyda net30 mae'r gweinydd yn dosbarthu bloc bach i bob cleient, felly nid oes llwybr i gyfeiriad tiwnel cleient arall oni bai bod y gweinydd yn ei anfon ymlaen. Gydag is-rwydwaith mae'r pwll cyfan yn un rhwydwaith, gall pob cleient gyfeirio at bob un arall, ac mae'r gweinydd yn anfon rhyngddynt. Dyna pam y gall un cyfluniad gweinydd edrych yn iach tra bod pingiau cymheiriaid yn methu: nid oes dim wedi torri, nid yw'r cleientiaid mewn un rhwydwaith yn syml. Mae'r cleient yn gweld cyswllt sy'n gweithio a chyfeiriad cymar nad yw'n ateb, sy'n darllen fel mur tân ond sy'n gynllun cyfeirio.

Mae newid y gyfarwyddeb yn olygiad ar ochr y gweinydd ynghyd ag ailgychwyn, ac mae'n berthnasol i'r cysylltiad nesaf yn hytrach nag i sesiynau sydd eisoes ar waith. Ailgysylltwch y cleientiaid cyn barnu'r newid. Os yw offeryn yn ailanhyrchu'r cyfluniad o ryngwyneb gwe, cofnodwch y gyfarwyddeb, y ffeil a'r dyddiad, a gwnewch yr olygiad drwy'r rhyngwyneb pan fo un, oherwydd bydd ailadeiladu yn trosysgrifo golygiad â llaw ar y cadw nesaf.

Mae client-to-client yn giât ar wahân

Hyd yn oed o fewn un is-rwydwaith mae'r gweinydd yn gollwng pecynnau sy'n dod o un cleient ac yn cael eu cyfeirio at un arall oni bai bod client-to-client wedi'i osod. Mae'r allweddair hwnnw'n troi'r gweinydd yn anfonwr ymlaen ar gyfer traffig cymheiriaid yn lle'n bwynt terfynol sy'n ei dderbyn yn unig. Dyma'r ail amod y mae pobl yn ei golli ar ôl trwsio'r dopoleg.

Nid yw'n ymestyn i ddarllediad. Mae'r gosodiad yn anfon unicast rhwng cleientiaid; nid yw'n troi'r tiwnel yn segment a rennir, ac ni fydd unrhyw faint ohono yn cyflwyno ymholiad darganfod multicast i bob cymar.

TUN yn erbyn TAP, a beth y gall pob un ei gynnal

Mae pontio dyfais tap i'r LAN yn rhoi cleientiaid o bell ym mharth darllediad y swyddfa, sy'n datrys darganfod yn llwyr. Y pris yw'r platfformau nad ydynt yn gweithredu TAP, pont y mae'n rhaid iddi fodoli ar y gweinydd, a pharth methiant lle mae storm ddarlledu ar wifren y swyddfa yn cyrraedd pob gliniadur o bell.

Ar gyfer dwy neu dair gorsaf waith sydd angen datrys enwau, mae cofnod hosts neu gyfeiriad unicast yn llawer rhatach na phont. Estynnwch am TAP pan fydd protocol na allwch ei ddisodli'n dibynnu ar ddarganfod haen-2, ac nid cyn hynny.

Cleientiaid yr un is-rwydwaith heb bont

Nid yw neilltuo cyfeiriad o amrediad y LAN yn rhoi'r cleient ar y wifren. Mae'r gweinydd yn llwybro rhwng tiwnel a Ethernet, felly mae ARP ar gyfer y cyfeiriad hwnnw'n stopio wrth ryngwyneb y gweinydd ac ni fydd gweddill y LAN byth yn dysgu ble mae'n byw.

ip neigh add proxy 10.50.1.250 dev eth0

Mae Proxy ARP yn cau'r bwlch hwnnw drwy i'r gweinydd ateb ar ran y cleient. Ar gyfer amrediad, mae parpd yn rheoli'r cofnodion wrth i gleientiaid ddod a mynd, tra bod y sysctl net.ipv4.conf.eth0.proxy_arp=1 yn ateb dros bopeth a lwybrir i ryfedd arall, sy'n ddigon eang i greu ei syndodau ei hun ar segment prysur.

Pa lwybr bynnag a gymerwch, tynnwch NAT rhwng y tiwnel a'r wifren. Mae rheol MASQUERADE yn cuddio'n union y cwestiwn cyfeirio rydych yn ceisio ei ateb. Mae hefyd yn gadael y person nesaf gyda thopoleg na all resymu yn ei chylch o ochr y cleient.

Cyn newid unrhyw beth, cofnodwch un ymgais ar y gweinydd gyda tcpdump -ni tun0 a chadarnhewch a yw pecyn y cymar yn cyrraedd o gwbl. Cyrraedd a chael ei ollwng sy'n pwyntio at client-to-client; peidio â chyrraedd byth sy'n pwyntio at dopoleg neu lwybro. Mae llawlyfr OpenVPN 2.6 yn dogfennu'r ddau allweddair a'r dopoleg ddiofyn, sy'n werth ei gymharu â'ch fersiwn cyn copïo llinell o swydd fforwm.

• Mae rhyngwyneb tun yn dangos mwgwd pwll yn hytrach na phâr cymar /30.
• Mae ping uniongyrchol i'r cyfeiriad tiwnel arall yn llwyddo cyn i chi brofi darganfod.
• Mae cyfluniad y gweinydd yn cynnwys client-to-client pryd bynnag y bydd yn rhaid i gymheiriaid gyfnewid pecynnau.
• Enwch y protocol darganfod rydych yn ei brofi yn lle dweud bod yr ap yn methu.
• Defnyddiwch TAP yn unig os yw pob platfform cleient yn y grŵp yn ei gefnogi.
• Cadwch NAT allan o'r llwybr rhwng tiwnel a LAN pan fo cyrraeddadwyedd o fewn yr un is-rwydwaith yn bwysig.