ફોનનું Wi-Fi Calling તોડ્યા વિના IPsec બ્લોક કરવું

વિનંતી હંમેશા એક જ આકારમાં આવે છે: કિનારે IPsec બંધ કરો કારણ કે તે એવી સુરંગો વહેવડાવે છે જે કોઈએ મંજૂર કરી નથી, અને પહેલી ફરિયાદ એવા વ્યક્તિ તરફથી આવે છે જેનો ફોન Wi-Fi પરથી કૉલ કરવાનું બંધ કરી ગયો છે. બંને હકીકતો એક સાથે સાચી છે, અને એક પણ નિયંત્રણ છોડવાનું વાજબી ઠેરવતી નથી. ફાયરવૉલને નામ આપેલી સુવિધા, મર્યાદિત સ્રોત, દસ્તાવેજીકૃત લક્ષ્યો અને માલિક સાથેનો સેવા-અપવાદ જોઈએ છે. પાંચ પગલાં તેને એવા નિયમમાં ફેરવે છે જે આવતા વર્ષે કોઈ અજાણી વ્યક્તિ સમીક્ષા કરી શકે.

પ્રોટોકોલનું નામ આપતાં પહેલાં સેવાનું નામ આપો

SIP સેવા પરનો ડેસ્ક ફોન અને ઑપરેટરનું Wi-Fi Calling કરતું હેન્ડસેટ એક જ નેટવર્ક પ્રોફાઇલ વહેંચતા નથી, અને ફાયરવૉલ શબ્દ તરીકે VoIP તેમાંના એકને પણ વર્ણવતું નથી. પોર્ટ અને લક્ષ્યની માહિતી સેવા ચલાવતા વેન્ડર અથવા ઑપરેટર પાસેથી આવવી જોઈએ, બીજી ફોન સિસ્ટમની યાદ રાખેલી પોર્ટ યાદીમાંથી નહીં. એ સુવિધાનું રક્ષણ કરતા નિયમ અને શબ્દનું રક્ષણ કરતા નિયમ વચ્ચેનો ફરક છે.

Apple નું સેવા-પોર્ટ સંદર્ભ Wi-Fi Calling માટે UDP 500 અને 4500 સૂચવે છે, જે મોટા ભાગના સામાન્ય IPsec બ્લોકો જે જોડી છોડી દે છે તે જ છે. તે પોર્ટની બાજુમાં ફેરફાર રેકોર્ડમાં સુવિધાનું નામ લખો. તમે વાપરેલા સંદર્ભની આવૃત્તિ કે તારીખ ઉમેરો, કારણ કે વેન્ડરના કોષ્ટકોમાં સંપાદન થાય છે. જે નિયમ જે સેવા માટે છે તેનું નામ લે છે તેની સમીક્ષા થઈ શકે; જે પ્રોટોકોલ શ્રેણીનું નામ લે છે તેની નહીં.

અપવાદને ઉપકાર નહીં, કરાર તરીકે લખો

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

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

કામચલાઉ ફોન સુધારો લેબલ ધરાવતી કાયમી પરવાનગી બે વર્ષ પછી રક્ષણીય નથી. ઓળખાયેલી સેવા સાથે બંધાયેલી પરવાનગીની સમાપ્તિ હોય છે જે જાણી જોઈને નવીકરણ થાય છે.

સ્રોતની મર્યાદા પ્રામાણિકતાથી નક્કી કરો

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

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

પોર્ટ નિયમ જે કહી શકતો નથી તે સ્વીકારો

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

તે નિયમની બાજુમાં કહો, અને અપવાદને નેટવર્ક પાસે જે અમલ છે તેની સાથે જોડો, જેમ કે ઉપકરણ વ્યવસ્થાપન કે મંજૂર લક્ષ્ય યાદી. પછી અપવાદને સાધન જેટલી મંજૂરી આપે તેટલી સાંકડી રીતે વ્યક્ત કરો, ઉદાહરણ તરીકે nftables નિયમો જે સેગમેન્ટ અને પોર્ટ જોડીનું નામ લે છે અને સામાન્ય નિષેધ તેમની પછી મૂકે છે:

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables ક્રમમાં મૂલ્યાંકન કરે છે અને પહેલા મેળ પર અટકે છે, તેથી મર્યાદિત મંજૂરી સામાન્ય નિષેધની ઉપર હોવી જોઈએ. બંને ઉલટાવો અને અપવાદ શાંતિથી કંઈ જ કરતો નથી.

સુવિધા અને નિષેધ ચકાસો

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

nft -a list chain inet edge forward

પરીક્ષણમાં ફરી જોડાણ કે નેટવર્ક ફેરફાર સામેલ કરો, અને ઠંડા શરૂઆતથી તેને પુનરાવર્તિત કરો જ્યાં ફોન નેટવર્કમાં જોડાય છે, પહેલેથી જોડાયેલો હોય તેમ નહીં. જો કૉલ નિષ્ફળ જતા હોય છતાં કાઉન્ટર આગળ વધે, તો સમસ્યા ફાયરવૉલ છોડી ગઈ છે અને ઑપરેટરની લક્ષ્ય યાદીની છે.