સ્પ્લિટ-ટનલ દસ્તાવેજોને દરેક રૂટની બાજુમાં DNS નિયમની જરૂર છે
રૂટ સરનામા પરથી નક્કી કરે છે, રિઝોલ્વર નામ પરથી નક્કી કરે છે. દરેક ફ્લો માટે બંને સિલેક્ટર દસ્તાવેજ કરો, દરેકને એક પરીક્ષા સાથે, નહીં તો DNS ખસે ત્યારે નોંધ નિષ્ફળ જાય.
એક સ્પ્લિટ-ટનલ નોંધ જે કહે છે "ઓફિસ ટ્રાફિક VPN દ્વારા જાય છે" તેણે એક નિર્ણય દસ્તાવેજ કર્યો છે અને અન્ય ત્રણ સૂચવ્યા છે. પેકેટ સ્તરે રાઉટિંગ કોષ્ટક ગંતવ્ય સરનામા દ્વારા ઇન્ટરફેસ પસંદ કરે છે; નામ સ્તરે રિઝોલ્વર ક્વેરી દ્વારા સર્વર પસંદ કરે છે, અને બંને પસંદગીઓ સ્વતંત્ર રીતે થાય છે. તેથી જ યોગ્ય રીતે દસ્તાવેજ કરેલો પ્રીફિક્સ હજી પણ એવી મશીન બનાવી શકે છે જે આંતરિક નામને જાહેર સરનામામાં રિઝોલ્વ કરે, અથવા રૂટ સંપૂર્ણ દેખાતો હોય ત્યારે કંઈ જ રિઝોલ્વ ન કરે.
બે સિલેક્ટર, એક કનેક્શન પ્રયાસ
જ્યારે એપ્લિકેશન files.corp.example સાથે જોડાય છે, ત્યારે પેકેટ અસ્તિત્વમાં આવે તે પહેલાં બે લુકઅપ થાય છે. રિઝોલ્વર નક્કી કરે છે કે કયો સર્વર ક્વેરી મેળવશે, સર્ચ ડોમેન, પ્રતિ-લિંક રાઉટિંગ ડોમેન અથવા સ્પષ્ટ પ્રોફાઇલ નિયમ વાપરીને. પછી રાઉટિંગ કોષ્ટક નક્કી કરે છે કે પરિણામી સરનામું ક્યાં જશે, ગંતવ્ય સાથે સૌથી લાંબા પ્રીફિક્સ મેળનો ઉપયોગ કરીને.
કંઈ પણ એ બે નિર્ણયોને જોડતું નથી. ખાનગી ઝોન 10.20.4.11 સાથે જવાબ આપી શકે છે જ્યારે રાઉટિંગ કોષ્ટક 10.20.0.0/16 ટનલમાં મોકલે છે, અને કનેક્શન કામ કરે છે. બેમાંથી કોઈ પણ ઉલટાવો અને તે બીજાના જેવું દેખાતી રીતે નિષ્ફળ જાય છે: સાચી DNS નીતિ ઉપરાંત ખૂટતો રૂટ રિઝોલ્વ થયેલું નામ અને સમયસમાપ્તિ આપે છે, જ્યારે સાચો રૂટ ઉપરાંત જાહેર રિઝોલ્વર એવું સરનામું આપે છે જે સ્વચ્છ રીતે ખોટી જગ્યાએ રાઉટ થાય છે.
સ્પ્લિટ-હોરાઇઝન DNS આને વધુ તીવ્ર બનાવે છે. એક જ નામ આંતરિક રિઝોલ્વરથી ખાનગી સરનામું અને ઇન્ટરનેટ તરફના રિઝોલ્વરથી જાહેર સરનામું પરત કરી શકે છે, તેથી ફક્ત પ્રીફિક્સ નોંધતી નોંધ અનુમાન કરી શકતી નથી કે ક્લાયન્ટ ખરેખર કયું સરનામું વાપરશે. રિઝોલ્વરનો માર્ગ લખો અથવા સરનામું એક અનુમાન છે.
ફક્ત-રૂટ નોંધ શું છોડી દે છે
ફક્ત-રૂટ રેકોર્ડ સૌથી સામાન્ય સ્પ્લિટ-ટનલ નિષ્ફળતા માટે નકામો છે: નામો. વપરાશકર્તા જણાવે છે કે ઇન્ટ્રાનેટ લોડ થતું નથી, ટનલ ચાલુ છે, અને પ્રીફિક્સ હાજર છે. જે ટિકિટ લે છે તેની પાસે કયા રિઝોલ્વરે જવાબ આપવો જોઈતો હતો તેનો કોઈ રેકોર્ડ નથી, ખોટા સર્ચ સફિક્સને બ્લોક કરેલા સર્વરથી અલગ પાડવાનો કોઈ રસ્તો નથી, અને સરખામણી માટે કોઈ આધારરેખા નથી.
બીજી છોડી દેવાની વસ્તુ અપવાદોની યાદી છે. સ્પ્લિટ-ટનલ ડિઝાઇન ટનલની બહાર શું રહે છે તેનાથી પણ એટલી જ વ્યાખ્યાયિત થાય છે જેટલી અંદર શું આવે છે તેનાથી, અને બાકાત રાખેલી શ્રેણીઓ સામાન્ય રીતે પહેલી તૂટે છે, કારણ કે વધુ ચોક્કસ સ્થાનિક રૂટ અથવા ક્લાયન્ટ-બાજુનું ફિલ્ટર પ્રોફાઇલને સ્પર્શ કર્યા વિના ઇરાદાને ઓળંગી શકે છે.
ત્રીજી ટનલની દૂરની બાજુ છે. ક્લાયન્ટ રૂટ પેકેટને ફક્ત વાયર પર મૂકે છે; ગેટવેએ હજી પણ તેને ફોરવર્ડ કરવું પડે છે અને પરત માર્ગ હોવો જોઈએ. strongSwan ની ફોરવર્ડિંગ માર્ગદર્શિકા યાદ કરાવે છે કે ગેટવે પરના ફોરવર્ડિંગ અને ફાયરવોલ નિયમો વિશેષતાનો ભાગ છે, એવી પ્લમ્બિંગનો ભાગ નહીં જેને તમે ધારી શકો.
નોંધને કાર્યાન્વિત કરતા ક્ષેત્રો
દરેક ફ્લો માટે એક પંક્તિ, અને ફ્લો એટલે ગંતવ્ય વત્તા નામ વત્તા માલિક. આ એ ક્ષેત્રો છે જે વાસ્તવિક ઘટનાના સંપર્કમાં ટકી રહે છે:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"તે ક્યાં રહે છે" પંક્તિ એ છે જે લોકો છોડી દે છે. સર્વર દ્વારા ધકેલાયેલો પ્રીફિક્સ, ક્લાયન્ટ પ્રોફાઇલ દ્વારા ઉમેરાયેલો રૂટ અને શેલમાં ટાઇપ કરેલો રૂટ એમાં અલગ પડે છે કે કોણ તેમને બદલી શકે છે અને શું તે પુનઃકનેક્શનમાં ટકે છે. તે ક્ષેત્ર વિના, આગલો એન્જિનિયર કહી શકતો નથી કે તે ત્રણમાંથી કયું જોઈ રહ્યો છે.
દરેક નિયમ માટે એક પરીક્ષા, દરેક ટનલ માટે નહીં
દરેક પંક્તિને બે નિરુપદ્રવી તપાસની જરૂર છે: એક જે રૂટનો ઉપયોગ કરે છે અને એક જે નામનો. રૂટ માટે, એવું કંઈક માંગો જે ટનલ પાર કરવું જ પડે અને પહોંચને બદલે માર્ગની પુષ્ટિ કરો, ઉદાહરણ તરીકે tracert -d 10.20.4.11 Windows પર અથવા ip route get 10.20.4.11 Linux પર. નામ માટે, ખાનગી નામની ક્વેરી કરો અને કયા સર્વરે જવાબ આપ્યો તે રેકોર્ડ કરો, નોંધ જે રિઝોલ્વરનું નામ આપે છે તેની સામે resolvectl query files.corp.example અથવા dig files.corp.example વાપરીને.
નકારાત્મક અપેક્ષા પણ ઉમેરો: ટનલ બંધ હોય ત્યારે શું થવું જોઈએ. VPN વિના બ્લોક સક્ષમ હોય તેવા Android અથવા iOS ઉપકરણ પરની બાકાત એપ્લિકેશનને કદાચ કોઈ કનેક્ટિવિટી જ ન હોય, અને ડેસ્કટોપ ક્લાયન્ટ ટનલ ફરી જોડાય ત્યારે પણ તે જ એપ્લિકેશનને કામ કરતી રાખી શકે છે. ઇચ્છિત જવાબ રેકોર્ડ કરવાથી "VPN એ મારી એપ્લિકેશન તોડી" ચકાસી શકાય તેવા વિધાનમાં ફેરવાય છે.
રેકોર્ડને રૂપરેખાંકન સાથે રાખો
નોંધને જે પ્રોફાઇલનું તે વર્ણન કરે છે તેની બાજુમાં સંગ્રહો અને તે પ્રોફાઇલ સાથે સંસ્કરણ કરો. વિકીમાંનું દસ્તાવેજ જેને કોઈ અપડેટ કરતું નથી તે અફવા છે; ધકેલાયેલા રૂટ અને રિઝોલ્વર નીતિ સાથેના એક જ ભંડારમાંનું કોષ્ટક એક જ ફેરફારમાં સમીક્ષા કરી શકાય છે.
કંઈ તૂટે ત્યારે, બીજો અપવાદ ઉમેરતા પહેલાં લાગુ કરેલા રૂટ અને અસરકારક રિઝોલ્વરને રેકોર્ડ સાથે સરખાવો. ત્રણ સામાન્ય કારણોમાંથી બે — જૂનો નેમસ્પેસ નિયમ અને એપ નીતિની બહારની સહાયક પ્રક્રિયા — બરાબર VPN ખામી જેવા દેખાય છે અને જો નોંધ ફક્ત પ્રીફિક્સની યાદી આપે તો અદૃશ્ય રહે છે.
નોંધને પૂર્ણ કહેતા પહેલાં ખાતરી કરો કે તે લેખિતમાં આનો જવાબ આપે છે: કયો પ્રીફિક્સ, કયા સરનામા કુટુંબ માટે; કયું ખાનગી નેમસ્પેસ, કયા રિઝોલ્વર દ્વારા જવાબ; કયા નામો જાણી જોઈને જાહેર રહે છે; દરેક નિયમ ક્યાં રૂપરેખાંકિત છે અને તેનો માલિક કોણ છે; અને એક જ આદેશ જે રૂટ સાબિત કરે છે અને એક જે નામ સાબિત કરે છે. જો તેમાંથી કંઈપણ ખૂટે, તો આગલી ઘટના શૂન્યથી નિદાન થશે.