OpenVPN ઘરે કામ કરે છે પણ એક નેટવર્ક પર નહીં: UDP કે TCP?

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

કયો તબક્કો નિષ્ફળ ગયો તે જણાવે છે કે કઈ સરખામણી મહત્વની છે

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

ફરી પ્રયાસ કરતી વખતે કેપ્ચર કરો, પછી નહીં. ક્લાયન્ટ પર, tcpdump -ni any udp port 1194 બતાવે છે કે કોઈ જવાબ પાછો આવે છે કે નહીં. તમે નિયંત્રિત કરો છો તેવા સર્વરના WAN ઇન્ટરફેસ પર તેને પુનરાવર્તિત કરો, જે દર્શાવે છે કે તે પેકેટો દૂરના છેડે પહોંચે છે કે નહીં.

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

UDP ફિલ્ટરિંગ સામે બંધ પોર્ટ

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

પોર્ટ 443 પર TCP પ્રોફાઇલ સામાન્ય ઉપાય છે, કારણ કે તે સામાન્ય HTTPS પ્રવાહ જેવું લાગે છે અને મોટાભાગના કેપ્ટિવ પોર્ટલ અને એગ્રેસ ફિલ્ટર પસાર કરે છે. બે શરતો પૂરી થવી જોઈએ. સર્વરે proto tcp-server સાથે સાંભળવું જોઈએ અને ક્લાયન્ટે proto tcp-client સાથે મેળ ખાવો જોઈએ, અને ઓપરેટરે તે વૈકલ્પિક એન્ડપોઇન્ટ પ્રકાશિત કરવો જોઈએ. કામ કરતી UDP પ્રોફાઇલને TCP 443 હોવાનો દાવો કરવા ફરી લખવાથી કંઈ ન થાય જ્યારે બીજા છેડે કોઈ સાંભળતું ન હોય.

બંધ પોર્ટ સેન્સરશિપની સમસ્યા નહીં, રૂપરેખાંકનની સમસ્યા છે. ઘરના રાઉટર પાછળનું સર્વર તેના UDP પોર્ટને ફોરવર્ડ કરવાની જરૂર ધરાવે છે, અને રાઉટરની ફાયરવોલે તેને મંજૂરી આપવી જોઈએ. જ્યારે પોર્ટને ક્યારેય મંજૂરી ન અપાઈ હોય, ત્યારે દરેક ક્લાયન્ટ ઓળખપત્રોને ધ્યાનમાં લીધા વિના વાટાઘાટમાં નિષ્ફળ જાય છે, અને નિષ્ફળતા નેટવર્કને બદલે સર્વરને અનુસરે છે.

જૂના પ્રોટોકોલ આ અક્ષ પર નબળી સરખામણી કરે છે. PPTP ને TCP 1723 ઉપરાંત GRE જોઈએ છે, અને GRE એ પોર્ટ નહીં પણ IP પ્રોટોકોલ 47 છે, તેથી કોઈ સામાન્ય પોર્ટ ફોરવર્ડ તેને વ્યક્ત કરતું નથી.

જ્યારે સ્વિચ જ પેકેટો ફેંકતું હોય

મેનેજ્ડ સ્વિચ ટનલને જાણી જોઈને ફેંકી શકે છે. કેટલાક HPE અને Aruba મોડેલ તેમના અદ્યતન સુરક્ષા વિભાગમાં UDP ફ્લડ સુરક્ષા નિયંત્રણ આપે છે, ક્યારેક Prevent UDP Blat Attack લેબલ સાથે. તે નિયંત્રણ સક્રિય હોય ત્યારે સ્વિચ પાછળનું સર્વર કંઈ જ જવાબ આપતું નથી અને દરેક ક્લાયન્ટ એ જ રીતે સમય સમાપ્ત થાય છે. તેને બંધ કરીને ચાલુ રૂપરેખાંકન સાચવવું એ જ આખું સમારકામ છે, પણ પહેલાં સ્થાપિત કરો કે સ્વિચ ખરેખર માર્ગમાં છે.

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

પ્રોફાઇલ બદલતા પહેલાં ક્લાયન્ટ અને સર્વર વચ્ચેના દરેક ઉપકરણ લખી લો. ખોટા સ્તરે લાગુ કરેલો સુધારો આગલા નેટવર્ક સુધી સાચો લાગે છે. તે યાદી આગલા ઇજનેરને આખી તપાસ પુનરાવર્તિત કર્યા વિના ક્યાં જોવું તે પણ કહે છે.

સરનામાંનું ઓવરલેપ જે DNS નિષ્ફળતા જેવું લાગે છે

10.0.0.0/8 ની અંદર ક્રમાંકિત એક્સેસ નેટવર્ક ટનલ પૂલ સાથે ઓવરલેપ થઈ શકે છે, અને રિઝોલ્વર સામાન્ય રીતે તે પૂલની અંદર જ રહે છે. જ્યારે લેપટોપને Wi-Fi પર /8 માસ્ક સાથે 10.184.178.50 જેવું સરનામું મળે, ત્યારે દરેક 10.x મંજિલ વ્યાખ્યા અનુસાર સ્થાનિક છે. 10.4.0.1 માટેના પેકેટો પછી LAN પર જાય છે, ટનલ ચાલુ રહે છે, અને નામનું નિરાકરણ નિષ્ફળ જાય છે.

ip addr ઓવરલેપને એક નજરે ઉજાગર કરે છે, અને ip route get 10.4.0.1 બતાવે છે કે પેકેટ ખરેખર ક્યાં પહોંચાડાશે. દેખાતું લક્ષણ રિઝોલ્વરની નિષ્ફળતા હોવાથી, આ કિસ્સો ઘણી વાર DNS ફેરફારોની ઘણી ફેરીઓ ટકી રહે છે.

પૂલને ફરી ક્રમાંકિત કરો અથવા તે એક્સેસ નેટવર્કને વ્યાપની બહાર રાખો. કોઈ પણ ક્લાયન્ટ-બાજુ સેટિંગ ઓવરલેપમાંથી પુનઃપ્રાપ્ત કરતું નથી.

TCP વૈકલ્પિક માર્ગ અને માર્ગ-સુધારા વચ્ચે નિર્ણય

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

પરિણામ વપરાશકર્તા પ્રમાણે નહીં, નેટવર્ક પ્રમાણે નોંધો. એ જ નિષ્ફળતાનો આગળનો અહેવાલ પછી પ્રમાણપત્રના સિદ્ધાંતને બદલે જાણીતા તબક્કાથી શરૂ થાય છે. તે નોંધ જ કાયમી બીજા શ્રોતાને ન્યાયી ઠેરવે છે, જો ક્યારેક જરૂર પડે.