નેસ્ટેડ WireGuard: મધ્યમ હોપ પોતાના પોર્ટ પર જવાબ આપી શકતું નથી
જ્યારે મધ્યમ હોપ બધું એક ટનલમાં મોકલે છે, ત્યારે તેની આવક સેવાના જવાબો ખોટા રસ્તે નીકળે છે. ઇન્ટરફેસ પર સ્રોત-પોર્ટ નિયમ તેને સુધારે છે.
ત્રણ WireGuard હોપ એવા નેટવર્ક સુધી પહોંચે છે જેનું કોઈ જાહેર સરનામું નથી, અને પછી મધ્યમ મશીન તે પોર્ટ પર જવાબ આપવાનું બંધ કરે છે જ્યાં તેણે સાંભળવાનું હતું. આગળની ટનલ હજી કામ કરે છે, દૂરનો હોસ્ટ હજી પ્રતિસાદ આપે છે, અને ફક્ત મધ્યમ સર્વર જ બહારથી શાંત થઈ ગયું છે. આ સંયોજન મૂંઝવણભર્યું છે કારણ કે તે સ્વયં સર્જિત છે: મધ્યમ હોપ પોતાના રાઉટિંગ કોષ્ટકને અનુસરે છે, અને કોષ્ટક તેના જવાબોને ખોટી દિશામાં મોકલે છે.
એક શૃંખલા જે મધ્યમ બોક્સ સાથે વાત ન કરો ત્યાં સુધી કામ કરે છે
એક દૃષ્ટાંતરૂપ શૃંખલા લો: ક્લાયન્ટ A UDP 500 પર સર્વર B સુધી પહોંચે છે, અને B UDP 500 પર સર્વર C તરફ આગળ વધે છે. C ફક્ત તેના એકમાત્ર પીઅરના સરનામેથી ટ્રાફિક સ્વીકારે છે, જે તેને પર્ણ બનાવે છે અને તેનું વર્તન સરળ રાખે છે. B પર્ણ નથી, અને આ નિષ્ફળતા વિશેનું બધું રસપ્રદ ત્યાં જ થાય છે.
આ ભેદ મહત્વપૂર્ણ છે કારણ કે પર્ણ અને મધ્યમ ભૂમિકાઓ વિરુદ્ધ દિશામાં ખેંચે છે. પર્ણ પરિણામ વિના બધું એક ટનલમાં મોકલી શકે છે, કારણ કે તેના પર બીજું કંઈ નિર્ભર નથી. મધ્યમ હોપ એકસાથે ક્લાયન્ટ માટે અંતિમ બિંદુ અને દૂરની બાજુ તરફ ક્લાયન્ટ છે, અને તે બે કાર્યો અલગ રાઉટિંગ ઈચ્છે છે.
જવાબ ટનલ દ્વારા કેમ નીકળે છે
B પર, C તરફનું ઇન્ટરફેસ અનુરૂપ ડિફોલ્ટ રૂટ સાથે AllowedIPs = 0.0.0.0/0 ધરાવે છે. તેથી B ઉત્પન્ન કરે છે તે દરેક પેકેટ તે ટનલમાં જાય છે, સિવાય કે વધુ ચોક્કસ કંઈક પ્રાધાન્ય મેળવે.
A થી B ને સંબોધિત પેકેટ આવે છે અને સ્વીકારવામાં આવે છે, કારણ કે B ગંતવ્ય છે અને સ્થાનિક વિતરણ પહેલા થાય છે. જવાબ સ્થાનિક રીતે ઉત્પન્ન થયેલું એકદમ નવું પેકેટ છે જે A ના જાહેર સરનામા તરફ નિર્દેશિત છે, અને તે ગંતવ્ય ટનલમાં જતા ડિફોલ્ટ રૂટ સાથે મેળ ખાય છે. C તેને મેળવે છે, તે સરનામાનો માલિક નથી, અને તેને ફેંકી દે છે.
લક્ષણ ફાયરવોલ સમસ્યા અથવા કી મેળ ન ખાવા જેવું લાગે છે, અને અહીં બંનેમાંથી એક પણ સાચું નથી. C તરફની ટનલ પરનું કેપ્ચર બતાવે છે કે જવાબો ખોટી દિશામાં જાય છે. તે એક અવલોકન કોઈપણ જેટલા રૂપરેખાંકન વાંચન કરતાં વધુ સમય બચાવે છે, તેથી કી બદલવાનું શરૂ કરતા પહેલા તેને લખી લો. જેણે કેપ્ચર જોયું નથી તે ધારશે કે ટનલ પોતે જ તૂટેલી છે.
સાંકડો સુધારો: સ્રોત પોર્ટ સાથે મેળ ખાતા નીતિ નિયમો
B ના સાંભળતા સોકેટમાંથી જવાબો સ્રોત પોર્ટ 500 સાથે નીકળે છે. નીતિ નિયમ તેની સાથે મેળ ખાઈ શકે છે અને તે પેકેટોને સામાન્ય કોષ્ટકમાં પાછા મોકલી શકે છે:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101નીતિ નિયમો પ્રાધાન્યક્રમમાં જોવામાં આવે છે, અને મુખ્ય કોષ્ટક 32766 પર બેસે છે, તેથી 100 પરનો નિયમ ટનલના ડિફોલ્ટ રૂટની પહેલાં પૂછવામાં આવે છે. બહારથી પહોંચી શકાય તેવા રહેવા જોઈતા દરેક પોર્ટ માટે એક એન્ટ્રી ઉમેરો અને વધુ કંઈ નહીં, જેથી ફોરવર્ડ કરાયેલ ટ્રાફિક જે ટનલ માટે બનાવાયું હતું તેનો ઉપયોગ ચાલુ રાખે.
આ યુક્તિની સીમા જાણો. sport પસંદક સ્થાનિક રીતે ઉત્પન્ન થયેલા પેકેટો સાથે મેળ ખાય છે, જે બરાબર જવાબના કિસ્સાને આવરી લે છે અને જાણી જોઈને એવા ટ્રાફિકને આવરી લેતું નથી જે B ફક્ત બીજા કોઈ માટે ફોરવર્ડ કરે છે. B પાછળ હોસ્ટ કરાયેલી સેવાને હજી પોતાનો જવાબ જોઈએ છે, અને વિરુદ્ધ હોવાનું દર્શાવવાથી એવો ઉપાય મળે છે જે પ્રથમ સેવા માટે કામ કરે છે અને બીજી માટે નિષ્ફળ જાય છે.
નિયમને માલિક આપો
પ્રોમ્પ્ટ પર લખાયેલો નિયમ આગલી વખતે ઇન્ટરફેસ ફરીથી બનાવાય ત્યારે અદૃશ્ય થઈ જાય છે. WireGuard સેટઅપમાં તેને ત્યાં મૂકો જ્યાં ઇન્ટરફેસ બનાવાય છે અને દૂર કરાય છે:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100જો NetworkManager, વિતરણ હૂક અથવા કન્ટેનર પ્રવેશબિંદુ ઇન્ટરફેસનું માલિક હોય, તો જોડી હાથે સંપાદિત ફાઇલમાં નહીં પણ તે માલિકની હોવી જોઈએ. ફરીથી જોડાણ પછી અસરકારક નિયમો તપાસો, ફક્ત પ્રથમ શરૂઆત પછી નહીં, કારણ કે પ્રથમ શરૂઆત એ કિસ્સો છે જે હંમેશા કામ કરે છે.
વિકલ્પોની પ્રામાણિક સરખામણી કરો
સ્રોત-પોર્ટ નિયમ ચાર રસ્તાઓમાંથી એક છે, અને તે સૌથી સાંકડો છે. તેનો ફાયદો એ છે કે તે ટનલ નીતિને બિલકુલ સ્પર્શતું નથી, અને તેથી તે પછીના ફેરફારોમાં ટકી રહે છે. સાંકડા સુધારા જ્યારે લાગુ પડવાનું બંધ કરે છે ત્યારે મોટેથી નિષ્ફળ જાય છે, જ્યારે વિશાળ અપવાદ તેનું કારણ અદૃશ્ય થયાને ઘણા સમય પછી પણ શાંતિથી કામ કરતો રહે છે. બે વર્ષ પછી જ્યારે બીજું કોઈ બોક્સનું માલિક હોય ત્યારે આ તફાવત સૌંદર્ય કરતાં વધુ મહત્વનો છે.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
પસંદ કર્યા પછી બંને છેડેથી ચકાસો. A થી, B ના પોર્ટ પર કનેક્શન શરૂ કરો અને થોડી વાર તેને વ્યસ્ત રાખો. B પર, કર્નેલને ip route get <address-of-A> sport 500 જેવા કંઈક સાથે જવાબ-માર્ગ વાજબી ઠેરવવા દો, અને ખાતરી કરો કે તે ટનલને બદલે WAN ઇન્ટરફેસનું નામ આપે છે. તે પછી, ચકાસો કે C પાછળનું કંઈક હજી શૃંખલા દ્વારા જવાબ આપે છે, જે સાબિત કરે છે કે અપવાદ બાયપાસ બનવાને બદલે સાંકડો જ રહ્યો. અંતે, પોર્ટ ડિઝાઇન નોંધોમાં નોંધો, નહીં તો આગલો ઓપરેટર આને બીજી સેવા પર ફરી શોધી કાઢશે.