બે VPN પૂલ માટે સ્રોત રાઉટિંગ: તમારો નિયમ શું ચૂકે છે
from સ્વરૂપનો નિયમ SNAT ફરીથી લખે તે પહેલાં ક્લાયન્ટ સરનામા સાથે મેળ ખાય છે, અને ગેટવેથી કરેલી કસોટી તેમાંથી કશા સાથે મેળ ખાતી નથી. દરેક પૂલ માટે શોધ ચલાવો અને તેના બદલે અગ્રતા વાંચો.
બે ક્લાયન્ટ પૂલ, એક ગેટવે, અને યોજના સાવ સાધારણ લાગે છે: એક નિયમ પહેલા પૂલને ઝડપી અપલિંક પર મોકલે છે, બીજો બીજા પૂલને પાર્ટનર ટનલમાંથી મોકલે છે. પછી નિયમો જગ્યાએ આવે છે અને બીજો પૂલ હજી પણ ડિફોલ્ટ રૂટથી નીકળે છે. નિયમ તૂટ્યો નથી. પેકેટનો સ્રોત એ નથી જે લેખકે શોધની ક્ષણે ધાર્યું હતું, કારણ કે અનુવાદ અને શોધ એક જ પેકેટની મુસાફરીના જુદા જુદા બિંદુઓ પર થાય છે, અને ક્રમ મોટાભાગના લોકો દોરે છે તે માનસિક આકૃતિનો ઉલટો છે.
શોધ સ્રોત ફરીથી લખાય તે પહેલાં થાય છે
VPN ક્લાયન્ટથી ફોરવર્ડ થતા પેકેટ માટે કર્નલ એક નિશ્ચિત ક્રમ ચલાવે છે. તે ટનલ ઇન્ટરફેસ પર આવે છે, preroutingમાંથી પસાર થાય છે જ્યાં conntrack અને DNAT રહે છે, પછી રાઉટિંગ નિર્ણય લેવાય છે, પછી ફોરવર્ડિંગ, પછી postrouting, જ્યાં SNAT સૌથી છેલ્લે લાગુ થાય છે. from સ્વરૂપનો નિયમ તે રાઉટિંગ નિર્ણય દરમિયાન જોવાય છે, એટલે કે તે ક્લાયન્ટનું મૂળ સરનામું જુએ છે, અનુવાદિત નહીં.
તેથી masquerade નિયમ ઉમેરવાથી બહાર જતા પ્રવાહ સાથે કઈ નીતિ મેળ ખાય છે તે બદલાતું નથી. જે બદલાય છે તે છે દૂરનો છેડો શું જુએ છે, અને તેથી કયો પરત માર્ગ અસ્તિત્વમાં છે. આ બે જુદા પરિણામો છે, અને ફેરફાર સમીક્ષાઓ તેમને સતત ભેળવી દે છે. તેમને અલગ કરો અને રચના સામાન્ય રીતે એક મિનિટમાં સ્પષ્ટ થઈ જાય છે.
જવાબની દિશામાં જ અનુવાદિત સરનામું નિયમોમાં દેખાય છે. ગેટવે પર પાછું આવતું પેકેટ અનુવાદિત સરનામા પર સંબોધિત હોય છે, અને જો તમારી પાસે ગંતવ્ય અથવા જે ઇન્ટરફેસથી તે આવ્યું તેના પર આધારિત નીતિ નિયમો હોય, તો તે જ મૂલ્ય તમે મેળવશો. એક જ કનેક્શન, દરેક દિશામાં જુદો સત્યનો સ્રોત.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
તેથી જુદા સ્રોતવાળા બે પૂલને ખરેખર જુદા ટેબલની જરૂર છે, અને રચના યોગ્ય છે. ઉપરનું ટેબલ જે બાકાત રાખે છે તે છે દૂરની સાઇટને શું મળ્યું તે જોઈને નિયમ અનુમાન કરવાનો ટૂંકો રસ્તો.
ગેટવેથી કરેલી કસોટી પૂલની કસોટી નથી
ગેટવે પોતે જે ટ્રાફિક પેદા કરે છે તે ક્યારેય preroutingમાંથી પસાર થતું નથી, કારણ કે તે કોઈ ઇન્ટરફેસ પર આવ્યું નથી. તે આઉટપુટ માર્ગમાં રાઉટ થાય છે, સ્રોત તરીકે ગેટવેનું પોતાનું સરનામું સાથે, અને ક્લાયન્ટ શ્રેણી પર બનેલો from નિયમ મેળ ખાશે નહીં. આ ક્ષેત્રની દરેક ટિકિટ જે કહે છે કે બોક્સથી કામ કરે છે પણ ક્લાયન્ટથી નહીં, તે એ જ હકીકતનું પુનરાવર્તન છે.
ક્લાયન્ટનું અનુમાન કરવાને બદલે તેનું અનુકરણ કરો. રાઉટિંગ શોધ સીધી પૂછી શકાય છે, સ્રોત અને ઇનગ્રેસ ઇન્ટરફેસ આપીને:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201દરેક પૂલ માટે એક વાર ચલાવો. જો બંને આદેશો એક જ ઇન્ટરફેસ પરત આપે, તો નિયમો પૂલને અલગ પાડતા નથી, અને કારણ ક્યાં તો ખૂટતો નિયમ કે બંને સાથે મેળ ખાતો વધુ અગ્રતાવાળો નિયમ છે. જો તે જુદા ઇન્ટરફેસ પરત આપે પણ ક્લાયન્ટ હજી નિષ્ફળ જાય, તો ખામી શોધ પછીની છે અને તમે નિયમો જોવાનું બંધ કરી શકો છો.
અગ્રતા, ફાઇલમાં સ્થાન નહીં
નિયમો અગ્રતાના ચઢતા ક્રમમાં મૂલ્યાંકિત થાય છે, અને સંખ્યા મહત્વની છે, તમે ટાઇપ કરેલો ક્રમ નહીં. local ટેબલ અગ્રતા 0 પર, main ટેબલ 32766 પર અને ડિફોલ્ટ નિયમ 32767 પર છે, તેથી ડિફોલ્ટ અગ્રતા સાથે ઉમેરાયેલો નિયમ યાદીના અંત નજીક પડે છે અને લગભગ બધા સામે હારી જાય છે.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201સ્પષ્ટ અગ્રતા ઇચ્છિત ક્રમને ફાઇલમાં અને સમીક્ષામાં દૃશ્યમાન બનાવે છે. તે પછીના ઉમેરણને શાંતિથી હાલના નિયમની આગળ કૂદવાથી પણ રોકે છે, જે અસંબંધિત ફેરફાર પછી કામ કરતી નીતિ કામ કરવાનું બંધ કરવાનું સૌથી સામાન્ય કારણ છે.
અપૂર્ણ ટેબલ તરફ ઇશારો કરતો મેળ ખાતો નિયમ બીજો સપાટો છે. જો ટેબલ 201માં ડિફોલ્ટ રૂટ હોય પણ ગંતવ્યનો રૂટ ન હોય, તો પેકેટ ફેંકાય છે અથવા ખોટી જગ્યાએ મોકલાય છે, અને નિયમ એકલો પૂર્ણપણે સાચો લાગે છે. ટેબલ વાંચો, ફક્ત નિયમ નહીં. નિયમ એ નિર્દેશક છે, અને ખાલી ટેબલ કંઈ પણ તરફનો નિર્દેશક છે.
પરત માર્ગ હજી પણ હોવો જોઈએ
સ્રોત નીતિ એક નિકાસ પસંદ કરે છે. તે પરત માર્ગ બનાવતી નથી. જો બીજો પૂલ પાર્ટનર ટનલમાંથી નીકળે, તો પાર્ટનરને 172.31.8.0/24 સુધી કેવી રીતે પહોંચવું તે ખબર હોવી જોઈએ, કાં તો ગેટવે તરફ પરત રૂટ દ્વારા કાં તો પહેલેથી જાણીતા અનુવાદિત સરનામાં મેળવીને.
તેમના વચ્ચે પસંદગી દૃશ્ય પરિણામોવાળો રચના નિર્ણય છે. ક્લાયન્ટ શ્રેણીને પાછી રાઉટ કરવાથી પાર્ટનર પાસે દરેક ક્લાયન્ટની ઓળખ જળવાય છે અને તેમને તમારો પ્રીફિક્સ સ્વીકારવો પડે છે. અનુવાદ પૂલને એક સરનામા પાછળ છુપાવે છે અને પાર્ટનરે ફક્ત તે સરનામું સ્વીકારવું પડે છે, જેની કિંમત એ છે કે તમારા અને તેમના લોગ હવે કોણ જોડાયું તેના પર સહમત નહીં થાય.
તમે જે પણ પસંદ કરો, તે પૂલની વ્યાખ્યા પાસે લખો. ફક્ત કોઈની યાદમાં રહેલો પરત રૂટ એ જ વસ્તુ છે જે પાર્ટનર ફાયરવોલ બદલે ત્યાં સુધી ટકે છે, અને પછી ફરી બનાવવા એક દિવસ લે છે.
નીતિમાં ગેટવેની પોતાની ટનલને ન પકડો
ક્લાયન્ટ માટે લખેલા નિયમો ગેટવે પેદા કરતા ટ્રાફિક પર પણ લાગુ પડે છે, સિવાય કે તમે તેને બાકાત રાખો. માર્ક અથવા આઉટપુટ ઇન્ટરફેસ પર બનેલો વ્યાપક નિયમ ગેટવેનું પાર્ટનર સાથેનું પોતાનું જોડાણ પકડી શકે છે, અને પછી નીતિ વહન કરતી ટનલ નીતિ દ્વારા રાઉટ થાય છે. તે લૂપ અથવા આઉટેજ પેદા કરે છે જે પ્રદાતાની ખામી જેવું લાગે છે.
દરેક નિયમને રચના પરવાનગી આપે તેટલો સાંકડો રાખો: સ્રોત પ્રીફિક્સ, ઇનગ્રેસ ઇન્ટરફેસ, અને જ્યાં સમર્થન હોય ત્યાં ફક્ત ક્લાયન્ટ પેકેટ ધરાવતો માર્ક. પછી દરેક નિયમ ફેરફાર પછી ગેટવેનું પોતાનું કનેક્ટિવિટી ચકાસો, કારણ કે ખામી સ્વ-સંદર્ભી છે અને ક્લાયન્ટ કસોટીમાં દેખાતી નથી.
ip-rule મેન્યુઅલ પૃષ્ઠ પસંદગીકાર અને અગ્રતાની અર્થઘટન દસ્તાવેજ કરે છે. તેને દરેક પૂલ માટેની શોધ કસોટી સાથે જોડો અને રચના ચકાસી શકાય તેવી બને છે, જે એક વર્ષ ટકતા નીતિ રાઉટિંગ અને બધા જેને સ્પર્શવાથી ડરે છે તેની વચ્ચેનો ફરક છે.