VPN સાઇડકાર માટે કિલ સ્વિચ: બહાર નીકળે ત્યારે ટ્રાફિક અવરોધો

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

નેમસ્પેસ શેર કરવું કિલ સ્વિચ કેમ નથી

નેમસ્પેસ શેર કરવાનો અર્થ એ છે કે એપ VPN કન્ટેનરના ઇન્ટરફેસ, સરનામાં અને રૂટ કોષ્ટક વાપરે છે. તે શેર કરેલ નેમસ્પેસ સુરક્ષિત રહે ત્યાં સુધી એપનો નેટવર્ક સુધીનો સ્વતંત્ર માર્ગ દૂર કરે છે, અને ટનલ જાય ત્યારે તે નેમસ્પેસ શું કરશે તે વિશે કંઈ કહેતું નથી.

Compose ની નિર્ભરતા શરતો એપની શરૂઆત નિર્ભરતા સ્વસ્થ ન થાય ત્યાં સુધી મોડી કરી શકે છે. આ સમયની એક ક્ષણને આવરે છે અને પછીની કોઈ નિષ્ફળતાને નહીં, તેથી તે શરૂઆતના ક્રમનું સાધન છે, સતત એગ્રેસ ફાયરવોલ નહીં.

કન્ટેનર બહાર નીકળે ત્યારે ખરેખર શું થાય છે

ત્રણ ઘટનાઓ અલગ કરો. કન્ટેનરની અંદરની VPN પ્રક્રિયા મરી શકે છે જ્યારે કન્ટેનર ચાલુ રહે. કન્ટેનર અટકી શકે છે અથવા દૂર કરી શકાય છે, જે નેમસ્પેસનો નાશ કરે છે. કન્ટેનર ફરી બનાવી શકાય છે, જે નવું નેમસ્પેસ અને નવા નિયમો બનાવે છે.

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

સ્પષ્ટ એગ્રેસ નીતિ બનાવો

નીતિ શેર કરેલ નેમસ્પેસની અંદર લખો જેથી તે એપના પેકેટ પર લાગુ પડે. આકાર અરુદ્ધ અપવાદો સાથે ડિફૉલ્ટ ડ્રોપ છે: loopback, ટનલનું ઇન્ટરફેસ, અને તે ચોક્કસ એન્ડપૉઇન્ટ સરનામું તથા પોર્ટ જે ટનલ પરિવહનને જરૂરી છે.

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

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

જીવનચક્ર ચકાસો, ફક્ત ડિસ્કનેક્ટ નહીં

ટનલ સ્વસ્થ હોય ત્યારે નવી હાનિરહિત વિનંતી મોકલો, પછી VPN પ્રક્રિયા મારો અને બીજી મોકલો. કન્ટેનર અટક્યા પછી, ફરી શરૂ કર્યા પછી અને ફરી બન્યા પછી પુનરાવર્તન કરો. નવી વિનંતી મહત્ત્વની છે કારણ કે હાલનું જોડાણ નવાંને અવરોધતા નિયમ ફેરફારમાંથી બચી શકે છે.

અવરોધની પદ્ધતિ તરીકે આરોગ્ય ચકાસણી કે એગ્રેસ IP શોધ પર આધાર ન રાખો. ચકાસણી સ્થિતિ જુએ છે અને તેની જાણ કરે છે; નીતિ ટ્રાફિક નિયંત્રિત કરે છે. બંને એક જ તૈનાતીના ભાગ છે, અને તે એકબીજાના વિકલ્પ નથી.

નિયમો નોંધો જેથી ચકાસણી સુધારા પછી ટકી રહે

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

VPN એન્ડપૉઇન્ટનો જરૂરી બાહ્ય માર્ગ એપના અમર્યાદિત એગ્રેસથી અલગ રાખો, અને DNS તથા IPv6 ને ઇચ્છિત આવરણમાં રાખો. જો નીતિ સુવિધા માટે આખું ભૌતિક ઇન્ટરફેસ પરવાનગી આપે, તો કિલ સ્વિચ ગયું છે. Docker ના નેટવર્ક દસ્તાવેજ તે શેર કરેલ નેમસ્પેસ ગોઠવણીનું વર્ણન કરે છે જેના પર નીતિ ઊભી છે, અને રનટાઇમના વર્તન પર શંકા હોય ત્યારે એ જ જોવાનો સંદર્ભ છે.