કેમ Access Server ક્લાયન્ટ LAN થી પહોંચી શકાતા નથી

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

સેવા જે સ્રોત સરનામું જુએ છે તે વાંચો

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

કંઈપણ બદલતા પહેલાં બંને છેડા સરખાવો. સર્વર પર ટનલ ઇન્ટરફેસ અને તેમના સરનામાં યાદી કરો; ક્લાયન્ટ પર ખાતરી કરો કે તે ખરેખર કયું સરનામું ધરાવે છે; આંતરિક હોસ્ટ પર જીવંત કનેક્શન જુઓ.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

જ્યાં જવાબ નક્કી થાય ત્યાં રૂટ ઉમેરો

રૂટ તે ગેટવે પર આવે છે જે આંતરિક સેવા પહેલેથી વાપરે છે, સેવા પર નહીં, સિવાય કે તે પોતાનું ટ્રાફિક રૂટ કરે. તેને Access Server ના પ્રાપ્ય ખાનગી સરનામા તરફ નિર્દેશ કરો, જે ક્લાયન્ટ ધરાવતા ટનલ સરનામાથી અલગ મૂલ્ય છે.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

ફોરવર્ડિંગ અને ફિલ્ટર રૂટ સાથે સંમત હોવા જોઈએ

રૂટિંગ માર્ગનો ફક્ત અડધો ભાગ છે. સર્વરને ટનલ અને ખાનગી ઇન્ટરફેસ વચ્ચે ફોરવર્ડ કરવાની મંજૂરી હોવી જોઈએ, જે લિનક્સ પર net.ipv4.ip_forward અને ઇન્ટરફેસની જોડીને મંજૂરી આપતી ફોરવર્ડ ચેઇન એમ બે અર્થ કરે છે, અને કઠોર હોસ્ટ પર સામાન્ય રીતે દરેક દિશા માટે સ્પષ્ટ નિયમ.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

સ્ટેટફુલ ફિલ્ટરિંગ એ લક્ષણ સમજાવે છે જે લોકોને ખોટા માર્ગે લઈ જાય છે. સ્થાપિત પ્રવાહની અંદરનો જવાબ નવો ઇનબાઉન્ડ નિયમ માગતો નથી, તેથી SYN-ACK પછી અટકતું કનેક્શન ખૂટતા સ્વીકાર નિયમથી અવરોધાતું નથી; તેને છોડી દેવાય છે અથવા ખોટું રૂટ થાય છે. એ ભેદ રાખો, કારણ કે તે રૂટિંગ ફેરફારને ફાયરવોલ ફેરફારથી અલગ પાડે છે.

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

રૂટેડ કે માસ્કરેડ: જાણી જોઈને પસંદ કરો

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

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

ક્લાયન્ટ પાછળનું સબનેટ અલગ કાર્ય છે

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

દિશા પણ નીતિનો પ્રશ્ન છે. ક્લાયન્ટને આંતરિક સેવા સાથે કનેક્શન ખોલવાની પરવાનગી આપોઆપ આંતરિક હોસ્ટને તે ક્લાયન્ટ સાથે કનેક્શન ખોલવાની પરવાનગી આપતી નથી. માર્ગ તૂટેલો છે એવું નિષ્કર્ષ કાઢતા પહેલાં સર્વરની એક્સેસ નીતિ અને ક્લાયન્ટની હોસ્ટ ફાયરવોલ તપાસો.

એક પ્રવાહ અને એક કેપ્ચર સાથે ચકાસો

સામાન્ય પ્રાપ્યતા પરીક્ષણને બદલે એક જ કનેક્શનથી માર્ગ સાબિત કરો. બંને છેડે એ જ પ્રવાહ જુઓ: સેવા પર આવતી વિનંતી અને તેને છોડતો જવાબ.

tcpdump -ni any host 10.90.0.25 and port 443

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

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