બધા પોર્ટ ફોરવર્ડ કરતા નિયમો તમારા WireGuard લિસનરને ગળી શકે છે
પહોળો ફોરવર્ડ નિયમ ગેટવેના પોતાના WireGuard અને SSH લિસનરને ગળી શકે છે. સાંકડા નિયમો અથવા અલગ જાહેર સરનામું પસંદ કરો, પછી નિયંત્રણ માર્ગ ચકાસો.
એક જાહેર ગેટવે પહેલેથી જ UDP 51820 પર WireGuard, 22 પર SSH અને ઇન્ટરનેટથી પહોંચવા જેવી એક એપ્લિકેશન ચલાવી રહ્યું છે. લલચાવતો નિયમ દરેક પોર્ટને peer પર ફોરવર્ડ કરે છે અને કામ પૂરું ઘોષિત કરે છે. WireGuard ગેટવે પર તે નિયમ ટનલની પોતાની વાહનવ્યવહાર પકડી શકે છે અને તમને તેને સમાપ્ત કરતી મશીનની બહાર તાળું મારી શકે છે. પ્રકાશન એ નિયંત્રણ સપાટીના અપવાદ સાથેનો રૂટિંગ નિર્ણય છે, એક DNAT લીટી નહીં.
જાહેર પ્રવેશ કે ટનલ પ્રવેશ: એક પસંદ કરો
સેવા પ્રકાશિત કરવાથી ઇન્ટરનેટ પર નવું પ્રવેશ બિંદુ બને છે. મુલાકાતી કદી ટનલમાં પ્રવેશતો નથી અને ગેટવે backendનું જાહેર ચહેરો બની જાય છે, તેથી આ peerને VPN સભ્યપદ આપવા જેવું નથી. તે ભેદ જ નિયમના પ્રેક્ષકો અને તેના પ્રમાણપત્ર નક્કી કરે છે.
વહીવટી ઇન્ટરફેસ તે સ્થાને ભાગ્યે જ બંધ બેસે. અધિકૃત VPN ક્લાયન્ટ પહોંચતું વહીવટી પૃષ્ઠ હુમલાની સપાટીને ટનલની અંદર રાખે છે અને લોગિન ફોર્મને મનસ્વી સ્કેનિંગ સામે ખુલ્લું મૂકવાનું ટાળે છે. જાહેર એપ્લિકેશન એન્ડપોઇન્ટને હજી પોતાનું TLS પ્રમાણપત્ર, પ્રમાણીકરણ અને દર મર્યાદા જોઈએ; એન્ક્રિપ્ટ થયેલ WireGuard કૂદકો મુલાકાતીના ગેટવે સુધીના ભાગની રક્ષા કરતો નથી.
જો સેવા ખરેખર જાહેર હોવી જ જોઈએ, તો હોસ્ટનામ, તેને આવરી લેતું પ્રમાણપત્ર અને તેના સુધી પહોંચવાના મુલાકાતી શ્રેણીઓ લખી લો. તે ત્રણ તથ્યો પછી નિયમનો આકાર અને ફિલ્ટર નીતિ નક્કી કરે છે. તેની બહારનું બધું જાહેર લિસનર પર વ્યાપ્તિ વિસ્તરણ છે.
એક પોર્ટ અંદર, એક backend બહાર
એક જ જાહેર પોર્ટ અને એક જ backend સેવા વાપરો. આ ઉદાહરણમાં eth0 જાહેર સરનામું 198.51.100.20 ધરાવે છે, ગેટવેનું ટનલ સરનામું 10.200.0.1 છે, અને peer એપ્લિકેશન 10.200.0.7 પર ચલાવે છે. જાહેર TCP 9443 peerના TCP 8443 પર મેપ થાય છે:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT નિયમ અનુવાદિત backend અને મૂળ જાહેર લક્ષ્ય સાથે મેળ ખાય છે, તેથી તે જ backend સેવાનું બીજું જોડાણ આ મેપિંગની બહાર રહે છે. તે મુલાકાતીનું સરનામું peerથી છુપાવે છે પણ, અને આ જ તે સમાધાન છે જે સ્રોત જાળવી રાખતા રૂટેડ પરત માર્ગને અલગ રચના બનાવે છે. iptables એક્સ્ટેન્શન સંદર્ભ બંને લક્ષ્યો અને તેમના મેળવણી વિકલ્પોનું દસ્તાવેજીકરણ કરે છે.
ફોરવર્ડિંગ હજી સક્ષમ હોવું જોઈએ, અને ફિલ્ટર શૃંખલાને અનુવાદિત લક્ષ્ય અને પોર્ટ તથા સ્થાપિત પ્રતિસાદ માટે પરવાનગી જોઈએ. FORWARD શૃંખલા DNAT પછીનું અનુવાદિત લક્ષ્ય જુએ છે, તેથી જાહેર સરનામા પર લખાયેલ નિયમ ફોરવર્ડ થતા પેકેટ સાથે મેળ ખાતો નથી. પરવાનગી જાહેર પર નહીં, backend ટપલ પર લખો.
peerએ ગેટવેના ટનલ સરનામેથી સેવા જોડાણ સ્વીકારવું જોઈએ અને પ્રતિસાદ ટનલ દ્વારા પાછો મોકલવો જોઈએ. તેનું AllowedIPs ખરેખર મળતા સ્રોતને અધિકૃત કરવું જોઈએ, જે સ્રોત અનુવાદ હેઠળ ગેટવેનું ટનલ સરનામું છે, અને આ રચના માટે દરેક peer પર પહોળી 0.0.0.0/0 નોંધ જરૂરી નથી. પરત વાહનવ્યવહાર પાડતું તે peer છે જેની યાદીમાં તે સરનામું નથી, અથવા તેના બદલે મુલાકાતીનું પોતાનું સરનામું ફોરવર્ડ કરતી સ્રોત જાળવતી રચના, તેથી તમારા નિયમમાંનું નહીં, peer ખરેખર જુએ છે તે સ્રોત તપાસો.
ગેટવેના પોતાના લિસનર નિયમની બહાર રાખો
પોર્ટ મેળવણીને દરેક TCP અને UDP લક્ષ્ય આવરી લેતા નિયમથી બદલો, અને ગેટવેનું પોતાનું WireGuard સોકેટ તેમાં આવી જાય છે. લક્ષ્ય અનુવાદ મશીન પેકેટ સ્થાનિક છે તેવું નક્કી કરે તે પહેલાં થાય છે, તેથી UDP 51820 દરેક peer જોડાણ રાખતી પ્રક્રિયાને બદલે peer સુધી પહોંચી શકે છે. નિયમ સફળતાપૂર્વક લોડ થાય છે અને ટનલ મરી જાય છે, જે peerની બાજુથી વાંચવી કઠિન નિષ્ફળતા છે.
SSH, દેખરેખ એજન્ટ અને ગેટવે પર હોસ્ટ કરેલી અન્ય કોઈ પણ સેવાને એ જ જોખમ છે. બધું ફોરવર્ડ કરતો નિયમ નિયંત્રણ સપાટીને પ્રકાશિત એપ્લિકેશનથી અલગ પાડતો નથી, અને ફેરફાર પછીનું પહેલું રીબૂટ એ ક્ષણ છે જ્યારે તાળું લાગ્યાનું સ્પષ્ટ થાય છે. બધું પકડતો નિયમ ચૂપચાપ સંભાળી લીધેલી સેવા વિશે ચેતવતો નથી. આગલું જોડાણ નિષ્ફળ થાય ત્યારે ખબર પડે છે.
જો પહોળું ફોરવર્ડિંગ ખરેખર જરૂરી હોય, તો બધું પકડતા નિયમ પહેલાં નિયંત્રણ પોર્ટ અનામત રાખો અથવા પ્રકાશન માટે અલગ જાહેર સરનામું વાપરો. બીજો વિકલ્પ સ્વચ્છ છે કારણ કે નિયંત્રણ સરનામું પોતાની નીતિ રાખે છે, પરંતુ પ્રદાતાએ તે સરનામું આપવું પડે; DNS રેકોર્ડ ઉમેરવાથી સરનામું ફાળવાતું નથી.
પહોળું TCP અને UDP ફોરવર્ડિંગ પણ બધા પ્રોટોકોલ નથી. ICMP, IPv6, path-MTU પ્રતિસાદ અને બાહ્ય VPN વાહનવ્યવહારને પોતાની નીતિ જોઈએ, અને TCP તથા UDP આવરી લેતો નિયમ તે કિસ્સાઓને ડિફોલ્ટ શૃંખલા પર છોડી દે છે.
નિયમો લખતા પહેલાં મોડેલ પસંદ કરો
ચાર આકાર ગેટવેથી થતા મોટા ભાગના પ્રકાશનોને આવરી લે છે, અને પસંદગી તમે કેટલી સેવાઓ ચલાવો છો અને નિયંત્રણ સપાટીમાં કેટલું જોખમ સહન કરી શકો છો તેના પર આધારિત છે. નીચેનું કોષ્ટક તેમને સૌથી સાંકડાથી સૌથી પહોળા સુધી ગોઠવે છે.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
પછી વધુ સેવાઓની અપેક્ષા હોય તો પણ સાંકડા મોડેલથી શરૂ કરો. તેનું ઓડિટ કરવું સૌથી સરળ છે, અને સાંકડા નિયમોના સમૂહને સમીક્ષિત બધું પકડતા નિયમમાં બદલવું, પહોળા નિયમે કયું લિસનર પકડ્યું તે શોધવા કરતાં સરળ છે. કોઈ પણ મોડેલ પસંદ કરો, નિયમો ફાયરવોલના માલિક પાસે રાખો. તે જ શૃંખલાઓનું સંચાલન કરતી UFW કે nftables રૂપરેખાની બાજુમાં iptables લીટીઓ લાગુ કરવાથી બૂટ ક્રમ પ્રમાણે બદલાતી નીતિ બને છે.
પ્રકાશન અને નિયંત્રણ માર્ગ બંને સાબિત કરો
અધિકૃત બાહ્ય ક્લાયન્ટથી મંજૂર હોસ્ટનામ અને તેના માટે માન્ય પ્રમાણપત્ર વાપરીને પરીક્ષણ કરો. કયા backendએ જવાબ આપ્યો તેની પુષ્ટિ કરો, પછી અસંબંધિત જાહેર પોર્ટ નકારાયેલા રહે છે તે તપાસો. અક્ષમ કરેલ પ્રમાણપત્ર તપાસ પાસ થયેલ HTTPS પરીક્ષણ નથી, અને ખોટા backend સુધી પહોંચતું જોડાણ નિષ્ફળ જોડાણ કરતાં ખરાબ છે.
ત્યાર બાદ ગેટવેને જ ચકાસો: એક WireGuard peer જોડો, એક SSH સત્ર ખોલો અને દેખરેખ હજી અહેવાલ આપે છે તેની ખાતરી કરો. નિયંત્રણ સપાટી તૂટેલી હોવા છતાં પ્રકાશિત સેવા કામ કરી શકે છે, તેથી બંને ચકાસણી એક જ ફેરફાર વિન્ડોમાં આવે છે. નિયમો અપેક્ષિત ક્રમમાં ફરી લાગુ થાય છે તે સાબિત કરવા એક વાર રીબૂટ કરો, પછી પ્રકાશન દૂર કરો અને દૂર કરવું ખરેખર ઉમેરવા સાથે મેળ ખાય છે તેની ખાતરી કરો. શરૂઆતમાં મોટા પ્રમાણમાં ઉમેરા અને અપૂર્ણ સફાઈ — કામચલાઉ પરીક્ષણ કાયમી છિદ્ર બનવાનો માર્ગ આ જ છે.