અલગ ઇગ્રેસ: usb0 પર VPN પૂલ, eth0 પર ગેટવે ટ્રાફિક

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

ખાતરી કરો કે સ્રોત સરનામું રાઉટિંગ નિર્ણય સુધી ટકે છે

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

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

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

સંપૂર્ણ હોય તેવું પસંદ કરેલ કોષ્ટક બનાવો

કોષ્ટક મિત્ર સાથેનો ડિફોલ્ટ રૂટ નથી. તેને પૂરતા રૂટની જરૂર છે જેથી દરેક લુકઅપ તેની અંદર જ ઉકેલાય, જેમાં WAN સબનેટનો જોડાયેલ રૂટનો સમાવેશ થાય જેથી આગળનો હોપ પહોંચી શકાય. tun1 પર 10.77.0.0/24 પૂલ, આગળના હોપ 203.0.113.1 સાથેનું WAN સરનામું 203.0.113.20/24, અને કોષ્ટક 600 માટે:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

નિયમ હાલના કોઈપણ બધું પકડતા નિયમથી નીચી પ્રાયોરિટી પર બેસે છે, તેથી મેળ ખાતા ક્લાયન્ટ પહેલા કોષ્ટક 600 પર પહોંચે છે અને બાકીનું બધું મુખ્ય કોષ્ટકમાં પડે છે. ip-rule સંદર્ભ ક્રમબદ્ધ લુકઅપ મોડલ અને સિલેક્ટર સિન્ટેક્સ સંપૂર્ણ રીતે વર્ણવે છે.

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

શ્રોતાનો પોતાનો ટ્રાફિક નીતિની બહાર રાખો

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

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

મશીન પરની બીજી કોઈપણ વસ્તુની તુલનામાં પણ ક્રમ મહત્ત્વનો છે. Docker બ્રિજ, બીજું VPN અને પ્રદાતાની ઇમેજના પહેલેથી હાજર કોઈપણ નિયમો બધા પ્રાયોરિટી ઉમેરે છે, તેથી પ્રાયોરિટી 100 એકલી છે એમ માનવાને બદલે આખી નિયમ યાદી વાંચો.

ફોરવર્ડિંગ અને અનુવાદને રૂટ સાથે મેળવો

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

જો બીજું WAN ખાનગી પૂલને તમારા તરફ પાછું રાઉટ ન કરે, તો તે ઇગ્રેસ પર સ્રોતનો અનુવાદ કરો. ગતિશીલ સરનામા ધરાવતા ઇન્ટરફેસ માટે પૂલ અને ઇન્ટરફેસ સુધી મર્યાદિત સાંકડો masquerade નિયમ સામાન્ય પસંદગી છે:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

માર્ગો અલગ પડે ત્યારે ટનલ ઓવરહેડ પણ ધ્યાન માંગે છે. જો ક્લાયન્ટ મોટું TCP MSS વાટાઘાટ કરે અને વૈકલ્પિક WANનું MTU નીચું હોય અથવા તેની અંદર ટનલ હોય, તો મોટા સેગમેન્ટ અટકે છે જ્યારે નાના કામ કરે છે. ફોરવર્ડિંગ માર્ગ પર MSS ક્લેમ્પ કરવાથી તે અવારનવાર અટકવાને બદલે અનુમાનિત વર્તન બની જાય છે.

usb0 અદૃશ્ય થાય ત્યારે શું થાય તે નક્કી કરો

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

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

ટકાઉપણું છેલ્લી વસ્તુ છે. બંને લિંકનો માલિક કોણ પણ હોય, પછી તે નેટવર્ક મેનેજર હોય, ડિસ્પેચર સ્ક્રિપ્ટ હોય કે કનેક્શનનું જીવનચક્ર, તેણે દરેક ફરી જોડાણ પર નકલ ઉમેર્યા વિના રૂટ અને નિયમ ફરી બનાવવા પડે. વાસ્તવિક ક્લાયન્ટની વિનંતી અને ગેટવેથી અલગ વિનંતી સાથે ચકાસો, બંનેમાં જોયેલું ઇગ્રેસ પુષ્ટિ કરો, પછી બીજું WAN ખેંચો અને જુઓ કે તમે ડિઝાઇન કરેલા બે પરિણામોમાંથી કયું ખરેખર થાય છે. IPv6ને તેનું પોતાનું કોષ્ટક, નિયમ અને અનુવાદ જોઈએ; ઉપરનો IPv4 નિયમ તેના વિશે કંઈ કહેતો નથી.