શા માટે ફક્ત route-nopull ફાઇલ સર્વરને અગમ્ય રાખે છે
ધકેલાયેલા રૂટને અવગણવો એ સ્પ્લિટ ટનલનો અડધો ભાગ છે. રૂટનો માલિક પસંદ કરો, ઓફિસ પ્રીફિક્સ જાતે ઉમેરો અને તેને ઠીક ગણાવતા પહેલાં ત્રણ પ્રવાહ ચકાસો.
ફાઇલ સર્વર બરાબર ખૂલે છે, અને બાજુની વિન્ડોમાં વિડિયો કૉલ થરથરવા લાગે છે. કંઈ ધીમું નથી અને કોઈ MTU ખોટું નથી: તમારા ક્લાયન્ટે સર્વરે આપેલી રૂટ યાદી સ્વીકારી લીધી, તેથી હવે દરેક પેકેટ ઓફિસ ફાયરવૉલમાંથી બહાર નીકળે છે. ઉકેલ બીજો ટ્યુનિંગ ફ્લેગ નથી પણ ક્લાયન્ટનું રૂટ ટેબલ કોનું છે તે અંગેનો નિર્ણય છે. એ નિર્ણય એક જ જગ્યાએ રહેવો જોઈએ, અને નીચેની નિષ્ફળતાની રીતો તમને કહે છે કે તમે ખરેખર કઈ જગ્યા પસંદ કરી.
નક્કી કરો કે રૂટ ટેબલ કોનું છે
ત્રણ માલિક શક્ય છે. સર્વર રૂટ અને ડિફૉલ્ટ ગેટવે ધકેલી શકે છે, એ સ્થિતિમાં ક્લાયન્ટ જે કહેવામાં આવે તે ઇન્સ્ટૉલ કરે છે અને સંપૂર્ણ ટનલ બને છે. ક્લાયન્ટ પ્રોફાઇલ ધકેલાવાને નકારીને અને પોતાની રૂટ લાઇનો રાખીને માલિકી લઈ શકે છે. ડેસ્કટૉપ કનેક્શન મેનેજર પણ પોતાના રૂટ અને ડિફૉલ્ટ-રૂટ ગુણધર્મો દ્વારા નિર્ણયનો માલિક હોઈ શકે છે.
દરેક પસંદગી અલગ રીતે નિષ્ફળ જાય છે, તેથી પ્રોફાઇલ સંપાદિત કરતા પહેલાં ટેબલ વાંચવું યોગ્ય છે. તમારા લક્ષણ સાથે મેળ ખાતી હરોળ એ જ માલિક છે જે તમારી પાસે ખરેખર છે.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
એક પસંદ કરો અને લખી લો. બે ભેળવવાથી એવો હોસ્ટ રહે છે જેનો ડિફૉલ્ટ માર્ગ તેના પોતાના દસ્તાવેજીકરણનો વિરોધ કરે છે, અને આગલો એન્જિનિયર કહી શકતો નથી કે કયો સ્તર જીત્યો. હારનારને સ્પષ્ટ રીતે કાઢી નાખો.
route-nopull ધકેલાવાને ગાળે છે, રૂટ ઉમેરતું નથી
route-nopull ક્લાયન્ટ પ્રોફાઇલમાં આવે છે, અને એ ફાઇલમાં તેનો ક્રમ મહત્ત્વનો નથી કારણ કે તે ફક્ત સર્વરથી આવતા મૂલ્યોને નકારે છે. તે ધકેલાયેલા રૂટને નકારે છે, ધકેલાયેલા ડિફૉલ્ટ રૂટ સહિત, જ્યારે ટનલ સામાન્ય રીતે ઉપર આવે છે.
લોકો જે પરિણામ ચૂકી જાય છે તે એ છે કે ધકેલાયેલા DHCP વિકલ્પો તેમની સાથે જાય છે. સર્વર મોકલેલા DNS સેટિંગ્સ પણ નકારાય છે, તેથી આંતરિક નામો ઉકેલાવાનું બંધ કરે છે, જોકે ટનલ સ્વસ્થ છે અને સર્વર સરનામાથી પહોંચી શકાય તેવું છે.
એનાથી ઓફિસ પ્રીફિક્સ સુધીના માર્ગ વગરની ટનલ રહે છે, સિવાય કે તમે જાતે એક ઉમેરો: એ જ પ્રોફાઇલમાં route-nopull પછી route 10.30.0.0 255.255.0.0. એ લાઇન સરનામું અને માસ્ક ધરાવે છે; તે આગલા હૉપનું નામ આપતી નથી.
વૈકલ્પિક સ્વરૂપ ગેટવે ટોકન ઉમેરે છે, route 10.30.0.0 255.255.0.0 vpn_gateway, જે એન્ટ્રીને નામથી ટનલ તરફ નિર્દેશ કરે છે. આયાતકર્તા એ બાબતમાં ભિન્ન છે કે તેઓ એ પ્રકારનું ભાષાંતર કરે છે કે નહીં, તેથી જો કર્નલ ટેબલમાં એન્ટ્રી ખૂટે તો સંગ્રહિત કનેક્શન તપાસો.
ping થી નહીં, રૂટ લુકઅપ દ્વારા ચકાસો
ping તમને કહે છે કે કંઈકે જવાબ આપ્યો. રૂટ લુકઅપ કહે છે કે કર્નલ કઈ ઇન્ટરફેસ પસંદ કરશે, અને એ જ પ્રશ્ન તમે ખરેખર પૂછ્યો હતો. ચાર ટૂંકા આદેશો ખૂટતા રૂટને ખોટા ઉપકરણ તરફ નિર્દેશ કરતા રૂટથી અલગ પાડે છે.
ટનલે શું ઇન્સ્ટૉલ કર્યું તે ip route show dev tun0 થી વાંચો. કોઈ આઉટપુટ ન હોવું એટલે શૂન્ય રૂટ, જે કામ કરતી સ્પ્લિટ ટનલ નથી, અને સ્પષ્ટ લાઇન વગર ફિલ્ટર ઉમેરવાનું આ સામાન્ય પરિણામ છે.
પછી ip route get 10.30.5.7 થી એક ઓફિસ સરનામું, અને ip route get 1.1.1.1 થી એક સામાન્ય ઇન્ટરનેટ સરનામું ચકાસો. બીજાએ ભૌતિક ઇન્ટરફેસનું નામ આપવું જોઈએ; જો તે ટનલનું નામ આપે, તો ધકેલાવો જરાય ગાળ્યો નથી.
છેલ્લે ip rule વાંચો, કારણ કે અગાઉના પ્રયાસે છોડેલો નીતિ નિયમ તમે હમણાં સુધારેલા ટેબલને માત કરી શકે છે. ઉપર જૂનો નિયમ ધરાવતી સાચી પ્રોફાઇલ બરાબર તૂટેલી પ્રોફાઇલ જેવી દેખાય છે. બીજો ઉમેરતા પહેલાં ગયા વખતે ઉમેરેલો નિયમ કાઢી નાખો.
એકબીજા પર ચઢતા સબનેટ તૂટેલી ટનલ જેવા દેખાય છે
ક્લાયન્ટની દૃષ્ટિએ બે ખાનગી રેન્જ સરખી હોઈ શકે છે, અને ત્યાં જ સ્પ્લિટ ટનલ પર એવી વસ્તુનો દોષ મૂકાય છે જે તેણે કરી નથી. જો ઓફિસ તમારા ઘરના રાઉટર જે પ્રીફિક્સ વાપરે છે તે જ આપે, તો ટનલ રૂટ રાઉટરને ઢાંકી દે છે અને ઘરનું નેટવર્ક અદૃશ્ય થયેલું લાગે છે.
કંઈ બદલતા પહેલાં સાદી સરનામા યાદી વાપરીને તમારા પોતાના ઇન્ટરફેસનું સરનામું પ્રોફાઇલ જે રૂટ ઇન્સ્ટૉલ કરે તેની સાથે સરખાવો. ઓવરલેપ વાસ્તવિક છે, અને કોઈ પ્રોફાઇલ વિકલ્પ તેને ઉકેલતો નથી. તમે જે સુધારી શકો તે નામકરણ છે, જેથી આગલી વ્યક્તિ એકને બદલે બે રેન્જ જુએ.
પ્રામાણિક ઉકેલ એક બાજુને ફરી નંબર આપવો અથવા ઓફિસમાં સરનામાંનું ભાષાંતર કરવું છે. રાઉટર સાથે એક જ હોસ્ટ રૂટ પિન કરવું ત્યાં સુધી કામ કરે છે જ્યાં સુધી રાઉટરનું સરનામું બદલાય, અને પછી તે પહેલાના ઉપર બીજું રહસ્ય બની જાય છે.
નિર્ણય ફરી જોડાવાને ટકી રહે તેમ કરો
હાથે ટાઇપ કરેલી એન્ટ્રીઓ ફરી જોડાવાને ટકતી નથી, અને કનેક્શન મેનેજર પ્રોફાઇલ શરૂ થાય ત્યારે દર વખતે ટેબલ ફરી બનાવે છે. નિર્ણય ત્યાં મૂકો જ્યાં કનેક્શન બને છે, પછી તે પ્રોફાઇલ હોય કે મેનેજરની સંગ્રહિત સેટિંગ્સ. પછી કૉલ દરમિયાન વર્તન શોધવાને બદલે એક વાર જાણી જોઈને કનેક્શન ફરી શરૂ કરો. જે પ્રોફાઇલ ફક્ત આગલા ફરી જોડાવા સુધી કામ કરે તે પૂરી નથી.
એકસાથે ત્રણ માર્ગો કસો: શાબ્દિક સરનામાથી ઓફિસ હોસ્ટ, નામથી એ જ હોસ્ટ, અને સામાન્ય જાહેર સાઇટ. વચ્ચેનો તમે ધકેલાયેલા DNS વિકલ્પો છોડ્યા પછી ગોઠવેલી નામ સેવા પર આધાર રાખે છે, અને ચૂપચાપ નિષ્ફળ જતો એ જ છે.