એક OpenVPN ક્લાયન્ટ પર બે સેવા સરનામાં: iroute અને lo

એપ્લિકેશન તેના ટનલ સરનામા પર જવાબ આપે છે, અને તમે તેના માટે દસ્તાવેજ કરેલું સરનામું ક્યાંય જતું નથી. OpenVPN લોગમાં કંઈ ફરિયાદ કરતું નથી, પીઅર જોડાયેલું દેખાય છે, અને હબ બરાબર એક ક્લાયન્ટની યાદી બતાવે છે. ખાલી જગ્યા એ છે કે ક્લાયન્ટ પરનું બીજું સરનામું બે અલગ હકીકતો છે: હોસ્ટે તેનું માલિકીપણું ધરાવવું જોઈએ, અને હબને ખબર હોવી જોઈએ કે કયો પીઅર તેનો માલિક છે. એકને બીજા વિના સંભાળો અને ટ્રાફિક કાં તો હબ પર મરી જાય છે અથવા ઘરે માર્ગ વિના પહોંચે છે.

ઉપનામ સ્થાનિક છે, માલિકી દૂરની છે

ટનલ સરનામું વાટાઘાટ થાય છે, તેથી હેન્ડશેક દરમિયાન બંને છેડા તેને શીખે છે. વધારાનું સેવા સરનામું બિલકુલ વાટાઘાટ થતું નથી, તેથી તે ઉમેરવાથી હબ પર પોતે કંઈ બદલાતું નથી. ક્લાયન્ટ તરત જ સરનામાનો માલિક બની શકે છે અને સર્વર તે ટ્રાફિક હજી પણ તેના ડિફૉલ્ટ માર્ગે મોકલશે અથવા તેને છોડી દેશે. બે રેકોર્ડ, બે અલગ જગ્યાએ બનાવવા પડશે.

ક્લાયન્ટ પર સરનામું હોસ્ટનું છે, અને લૂપબેક એ સેવા ઓળખ માટે કુદરતી ઘર છે જે ક્યારેય ભૌતિક લિંક પર દેખાવું ન જોઈએ. હબ પર પીઅર-થી-પ્રીફિક્સ મેપિંગ એ અલગ ઘોષણા છે જે ફક્ત સર્વર વાંચે છે. બેમાંથી કોઈ રેકોર્ડ બીજાને સૂચિત કરતું નથી.

તમારી નોંધમાં પણ બે શ્રેણીઓ અલગ રાખો. ઉદાહરણના સરનામાં દસ્તાવેજીકરણના મૂલ્યો છે, અને તેમને વાસ્તવિક LAN સાથે ઓવરલેપ કરવું એ કાર્યરત સેટઅપને તૂટેલું દેખાડવાનો સૌથી ઝડપી રસ્તો છે.

ક્લાયન્ટ પર સરનામું કાયમી રૂપે ઉમેરો

સેવા સરનામાને હોસ્ટ પ્રીફિક્સ સાથે લૂપબેક પર મૂકો, જેથી હોસ્ટ તેને પહોંચવાના સબનેટ તરીકે નહીં પણ સ્થાનિક ઇનપુટ તરીકે ગણે. ip address add 10.66.0.10/32 dev lo એક સરનામા માટે એ કરે છે, અને બીજા સરનામા માટે આદેશનું પુનરાવર્તન બે સેવાઓનું મોડેલ બનાવે છે.

તેને એક વખતની કસોટી તરીકે ચલાવો, પછી તેને જે હોસ્ટના નેટવર્ક કન્ફિગરેશનનું માલિક છે તેમાં ખસેડો, કારણ કે રનટાઇમ ઉમેરો રીબૂટ પર અદૃશ્ય થાય છે અને ફરીથી જોડાણો વચ્ચે નકલો એકઠી થાય છે. નેટવર્ક પછી ક્રમબદ્ધ systemd યુનિટ એક વિકલ્પ છે, અને ડિસ્ટ્રિબ્યુશન નેટવર્ક મેનેજર બીજો છે. તમે જે પણ પસંદ કરો, એપ્લિકેશન જોડાય તે પહેલાં સરનામું અસ્તિત્વમાં હોવું જોઈએ, નહીં તો સેવા ખોટા સોકેટ પર ઉપર આવે છે. મેન્યુઅલ આદેશ પછી નહીં, રીબૂટ પછી ip address show dev lo થી ચકાસો.

બાઇન્ડિંગ એ સરનામાંકનથી અલગ નિર્ણય છે. દરેક સરનામા પર સાંભળતી એપ્લિકેશન તમે ક્યારેય ઇરાદો ન હોય તેવા ઇન્ટરફેસ પર ટ્રાફિક સ્વીકારે છે, તેથી તેને ચોક્કસ સેવા સરનામા તરફ નિર્દેશિત કરો. પછી સ્થાનિક ઇનપુટ નીતિ પાસે ચોક્કસ મેળ કરવા માટે કંઈક હોય છે.

હબ ખરેખર જે CCD ફાઇલ વાંચે છે તેમાં તેનો દાવો કરો

સર્વર પર, માલિકીની ઘોષણા પ્રમાણિત સામાન્ય નામ દ્વારા પસંદ કરાયેલી પ્રતિ-ક્લાયન્ટ ફાઇલમાં જાય છે, client-config-dir દ્વારા નામ આપેલી ડિરેક્ટરીની અંદર. લાઇન iroute 10.66.0.10 255.255.255.255 છે, પ્રતિ સરનામે એક, અને તે સર્વરને કહે છે કે તે ગંતવ્ય માટે કયા પીઅરને ટ્રાફિક મળવો જોઈએ.

બે વિગતો આને શાંતિથી તોડે છે. ફાઇલનું નામ સર્વર ખરેખર જે નામ વાપરે છે તેની સાથે મેળ ખાવું જોઈએ, જે username-as-common-name રમતમાં હોય ત્યારે અલગ હોય છે. અને iroute ફક્ત TUN મોડમાં ક્લાયન્ટ કન્ફિગરેશન ડિરેક્ટરી કન્ફિગર થયેલી હોય ત્યારે જ અમલમાં આવે છે, તેથી બ્રિજ્ડ ડિપ્લોયમેન્ટમાં એ જ લાઇન કંઈ કરતી નથી. હાલની ફાઇલમાં લાઇન ઉમેરો, તેને બદલો નહીં, કારણ કે તે પહેલેથી નિશ્ચિત સરનામું અથવા push વિકલ્પો ધરાવી શકે છે. OpenVPN 2.6 સંદર્ભ ડિરેક્ટરી અને માલિકી નિર્દેશ બંનેનું દસ્તાવેજીકરણ કરે છે.

હબના પોતાના કર્નલને પણ તે ગંતવ્યો સુધીનો માર્ગ જોઈએ છે જેથી સ્થાનિક રીતે ઉત્પન્ન થયેલો ટ્રાફિક ટનલ પ્રક્રિયામાં પ્રવેશે. સર્વર કન્ફિગરેશનમાં route 10.66.0.10 255.255.255.255 સર્વર પોતે ઉત્પન્ન કરે તે ટ્રાફિકને આવરી લે છે, જ્યારે અન્ય ક્લાયન્ટ્સને ગંતવ્ય જાતે શીખવા push "route 10.66.0.10 255.255.255.255" ની જરૂર છે.

રૂટિંગ અને અધિકૃતિ અલગ રહે છે. ધકેલાયેલો માર્ગ ક્લાયન્ટને કહે છે કે પેકેટ ક્યાં મોકલવા, અને કંઈ આપતું નથી; સેવાએ હજી પણ કૉલરને તેની પોતાની શરતો પર સ્વીકારવો પડે છે.

ઇનપુટ નીતિ અને જવાબ માર્ગ ચકાસો

ઉપનામને સંબોધિત પેકેટ માલિક હોસ્ટ પર સ્થાનિક ઇનપુટ તરીકે પહોંચે છે, તેથી પ્રશ્ન એ છે કે સ્થાનિક ફાયરવૉલ તે સ્રોત અને પોર્ટને મંજૂરી આપે છે કે નહીં. આખું સરનામું ખોલવાને બદલે VPN સ્રોત શ્રેણીમાંથી ચોક્કસ સેવા પોર્ટને મંજૂરી આપો.

જવાબોને કૉલર સુધી પરત માર્ગ જોઈએ છે. સામાન્ય ટનલ પૂલની અંદરના કૉલર માટે તે માર્ગ પહેલેથી અસ્તિત્વમાં છે, કારણ કે ટનલ ઉપકરણ તેને વહન કરે છે. બીજા રૂટેડ નેટવર્ક પાછળના કૉલરને તે નેટવર્કનો પરત માર્ગ પણ જોઈએ છે, અને અહીં જ અસમમિત સેટઅપ પેકેટ ગુમાવે છે.

એ જ પોર્ટ પર બીજા સરનામે બંધાયેલા બીજા શ્રોતા પર ધ્યાન રાખો, કારણ કે કર્નલ જે સોકેટ મેળ ખાય તેને પહોંચાડે છે અને પરિણામો અવ્યવસ્થિત લાગે છે. ss -lntp થી ચકાસો અને ખાતરી કરો કે બંધાયેલું સરનામું સેવા ઉપનામ છે. અહીં સ્રોત NAT જરૂરી નથી, અને તે ઉમેરવાથી તમારા લોગ જે કૉલર ઓળખ પર આધાર રાખે છે તે છુપાય છે.

સરનામાં અને માલિકી અલગથી ચકાસો

બે પગલામાં ચકાસો. પહેલા ખાતરી કરો કે માલિક હોસ્ટ પોતાના ઉપનામ પરની સેવા સુધી પોતાની જાતથી પહોંચી શકે છે, જે બાઇન્ડ અને ફાયરવૉલ સમસ્યાઓને રૂટિંગથી અલગ કરે છે. પછી એપ્લિકેશનની પોતાની પ્રમાણીકરણ વાપરીને વાસ્તવિક VPN કૉલરથી ચકાસો. જ્યારે પહેલું પાસ થાય અને બીજું નિષ્ફળ જાય, ત્યારે ખૂટતો ટુકડો હબની બાજુ છે.

કનેક્શન પછી પણ ટકી રહેતા નિષ્ફળતાના પ્રકારો પણ ચકાસો: ટનલ બંધ હોય ત્યારે ઉપનામ સોંપાયેલું રહે છે, અને પીઅર ગેરહાજર હોય ત્યારે હબ તેનો માર્ગ રાખે છે. કોઈ પણ વસ્તુ એકલી સાબિત કરતી નથી કે સેવા પહોંચી શકાય તેવી છે, તેથી બે-પગલાની કસોટી લેપટોપથી એક પિંગ કરતાં સારી છે.