OpenVPN ક્લાયન્ટ એકબીજાને જોઈ શકતા નથી: સબનેટ કે net30?
ક્લાયન્ટ સર્વર સુધી પહોંચે છે પણ એકબીજા સુધી નહીં. એક ping થી ખામી અલગ કરો, પછી સબનેટ ટોપોલોજી, client-to-client અથવા બ્રિજ કરેલ TAP સેગમેન્ટ પસંદ કરો.
બે અસંબંધિત ખામી એ જ ફરિયાદ ઉત્પન્ન કરે છે. પ્રથમમાં એક ક્લાયન્ટ બીજા સુધી ટનલ સરનામા દ્વારા પણ પહોંચતો નથી, કારણ કે સરનામાં એક જ સબનેટમાં નથી અથવા સર્વર પીઅર ટ્રાફિક ફોરવર્ડ કરતું નથી. બીજામાં ping કામ કરે છે અને એપની ઉપકરણ યાદી ખાલી રહે છે, કારણ કે શોધ 3 લેયરની ટનલ વહન કરી શકે નહીં તેવા બ્રોડકાસ્ટ પર આધાર રાખે છે. એક ping બંનેને અલગ કરે છે, અને દરેકનો ઉપાય બીજાના ઉપાય જેવો જરાય નથી.
એક ping સમસ્યાને બે ભાગમાં વહેંચે છે
એક ક્લાયન્ટથી બીજા ક્લાયન્ટના ટનલ સરનામાને ping કરો, તેના નામને નહીં અને તેના LAN સરનામાને નહીં. જો તે નિષ્ફળ જાય, તો ફોરવર્ડિંગ કે એડ્રેસિંગ સમસ્યા છે અને તે ઠીક ન થાય ત્યાં સુધી શોધ અપ્રસ્તુત છે. જો તે સફળ થાય, તો ફોરવર્ડિંગ પહેલેથી કામ કરે છે અને બાકીની ખાલી જગ્યા બ્રોડકાસ્ટ કે નામ નિરાકરણ છે.
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 સેટ ન હોય. એ કીવર્ડ સર્વરને ફક્ત સ્વીકારનારા અંતિમ બિંદુને બદલે પીઅર ટ્રાફિકનું ફોરવર્ડર બનાવે છે. ટોપોલોજી ઠીક કર્યા પછી લોકો જે બીજી શરત ચૂકી જાય છે તે આ છે.
તે બ્રોડકાસ્ટ સુધી વિસ્તરતું નથી. સેટિંગ ક્લાયન્ટ વચ્ચે યુનિકાસ્ટ ફોરવર્ડ કરે છે; તે ટનલને વહેંચાયેલ સેગમેન્ટ બનાવતું નથી, અને તેનો કોઈ પણ જથ્થો મલ્ટિકાસ્ટ શોધ ક્વેરી દરેક પીઅર સુધી પહોંચાડશે નહીં.
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 માં બ્રિજ કરવાથી દૂરસ્થ ક્લાયન્ટ ઓફિસના બ્રોડકાસ્ટ ડોમેનમાં આવે છે, જે શોધને સંપૂર્ણ રીતે ઉકેલે છે. કિંમત એ પ્લેટફોર્મ છે જે TAP અમલમાં મૂકતા નથી, સર્વર પર હોવો જોઈએ તેવો બ્રિજ, અને નિષ્ફળતાનું ક્ષેત્ર જ્યાં ઓફિસના કેબલ પરનું બ્રોડકાસ્ટ તોફાન દરેક દૂરસ્થ લેપટોપ સુધી પહોંચે છે.
નામ નિરાકરણની જરૂર હોય તેવા બે કે ત્રણ વર્કસ્ટેશન માટે hosts એન્ટ્રી કે યુનિકાસ્ટ સરનામું બ્રિજ કરતાં ઘણું સસ્તું છે. TAP તરફ ત્યારે જ જાઓ જ્યારે તમે બદલી ન શકો તેવો પ્રોટોકોલ 2 લેયરની શોધ પર આધાર રાખે, અને તે પહેલાં નહીં.
બ્રિજ વગરના એક જ સબનેટના ક્લાયન્ટ
LAN રેન્જમાંથી સરનામું આપવું ક્લાયન્ટને કેબલ પર નથી મૂકતું. સર્વર ટનલ અને ઇથરનેટ વચ્ચે રૂટ કરે છે, તેથી તે સરનામા માટે 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 વચ્ચેના માર્ગની બહાર રાખો.