FortiClient સંપૂર્ણ ટનલ: ફક્ત ઓફિસ સબનેટ રૂટ કરો

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

ક્લાયન્ટે શું ઇન્સ્ટોલ કર્યું, અને LAN કેમ અદૃશ્ય થઈ ગયું

ક્લાયન્ટ ઇન્ટરફેસને બદલે ટેબલ વાંચીને શરૂ કરો. macOS પર netstat -rn આખું ટેબલ છાપે છે અને route -n get default હાલમાં જીતતું ઇન્ટરફેસ અને મેટ્રિક જણાવે છે; Linux પર જોડી ip route show અને ip route get 8.8.8.8 છે. બંને એક પ્રશ્નનો જવાબ આપે છે: કઈ એન્ટ્રી એવું પેકેટ વહન કરશે જે વધુ ચોક્કસ કંઈપણ સાથે મેળ ખાતું નથી.

ટનલ ઉપકરણનું નામ નિશ્ચિત નથી. macOS પર IKEv2 પ્રોફાઇલ સામાન્ય રીતે નંબર સાથે utun દર્શાવે છે, SSL VPN ક્લાયન્ટ ppp0 દર્શાવે છે, અને OpenVPN tun0 દર્શાવે છે. બે ડિફોલ્ટ રૂટ પણ એક જ સમયે જુદા જુદા મેટ્રિક સાથે હાજર હોઈ શકે છે, અને ક્લાયન્ટ એન્ટ્રી દેખાય તે ક્ષણે નહીં પણ ફરી જોડાણ પછી જ સત્તા લઈ શકે છે. તેથી પાંચ મિનિટના અંતરે લીધેલા બે ટેબલ ડમ્પ જુદી જુદી વાર્તાઓ કહી શકે છે.

ટનલ ડિફોલ્ટ રૂટ પહેલા કેમ જવો જોઈએ

કર્નલ સૌથી લાંબું મેળ ખાતું પ્રીફિક્સ પસંદ કરે છે, અને જ્યારે ઘણા રૂટ સમાન રીતે ચોક્કસ હોય ત્યારે સૌથી નીચા મેટ્રિકવાળું પસંદ કરે છે. તેથી જે ક્લાયન્ટ 0.0.0.0/0 વધુ સારા મેટ્રિક સાથે ઇન્સ્ટોલ કરે છે તે મૂળ ડિફોલ્ટ ન ભૂંસતાં દરેક ગંતવ્ય જીતી લે છે, અને તેથી જ ભૌતિક રૂટ હજી ટેબલમાં છે અને હજી વિક્ષેપ સમજાવે છે. ટનલ ડિફોલ્ટ રૂટ પહેલા દૂર કરવાથી અગાઉનું વર્તન પુનઃસ્થાપિત થાય છે. ત્યાર પછી જ ટનલ દ્વારા પ્રીફિક્સ રૂટ તે કરે છે જે તેના લેખકનો ઉદ્દેશ હતો.

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

macOS અને Linux પરનો ક્રમ

macOS પર ક્રમ ટનલ ડિફોલ્ટ રૂટ ભૂંસે છે, ભૌતિક ડિફોલ્ટ રૂટ પુનઃસ્થાપિત કરે છે અને એક ઓફિસ પ્રીફિક્સ ટનલમાં પાછું મોકલે છે. અહીંના ઉદાહરણના ઇન્ટરફેસ નામોને તમારા પોતાના ટેબલના નામોથી બદલો.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

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

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

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

પ્રીફિક્સ, રિઝોલ્વર અને અંધારામાં રહેતું DMZ

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

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

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

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

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

આગલા જોડાણ પછી, અને આ સ્થાનિક રીતે કરવાનું ક્યારે બંધ કરવું

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

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

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