VPN ક્લાયન્ટને ટનલ પર એકબીજા સુધી પહોંચતા રોકો

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

શેર કરેલી સેવા સુધીનો માર્ગ પીઅર વચ્ચે પરવાનગી નથી

ક્લાયન્ટ સબનેટની જાહેરાત પીઅરને કહે છે કે બીજા ક્લાયન્ટના સરનામા તરફ પેકેટ કેવી રીતે તાર પર મૂકવું. તે પેકેટ પહોંચશે કે નહીં તે પછી નક્કી થાય છે, જે તેને ફોરવર્ડ કરે છે તેના દ્વારા. Linux ગેટવે પર તે FORWARD શૃંખલા છે; વપરાશકર્તા-અવકાશના ડિમનની અંદર તે ટનલનું પોતાનું સત્ર કોષ્ટક છે. માર્ગ પહોંચનીયતાનો જવાબ આપે છે અને પરવાનગીને અસ્પૃશ્ય રાખે છે.

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

ટર્મિનલ ખોલતા પહેલા આવશ્યકતા એક લીટીમાં લખો. સેવા બ્લોક અને જમ્પ હોસ્ટ સુધી પહોંચો, ક્લાયન્ટ બ્લોકની અંદર બીજે ક્યાંય ન પહોંચો.

પીઅર પેકેટ ખરેખર કોણ ફોરવર્ડ કરે છે તે શોધો

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

WireGuard પહેલા જૂથનું છે: તેમાં પીઅર-થી-પીઅર સ્વિચ નથી, તેથી 10.8.0.4 થી 10.8.0.5 સુધીનું પેકેટ wg0 પર આવે છે, ફોરવર્ડ હૂકને અડે છે અને જ્યારે AllowedIPs બંને સરનામાં ઢાંકે છે ત્યારે ફરી wg0 માંથી માર્ગ કરવામાં આવે છે. OpenVPN બીજું જૂથ છે જ્યારે સર્વર ગોઠવણીમાં client-to-client સેટ હોય, કારણ કે તે નિર્દેશ પેકેટને વપરાશકર્તા અવકાશમાં સત્રો વચ્ચે સોંપે છે. કંઈ પણ લખતા પહેલા લોડ થયેલી ગોઠવણીમાં તે નિર્દેશ તપાસો. જે કર્નલ નિયમ ક્યારેય ટ્રાફિક જોતો નથી તેને કામ કરતા નિયમથી અલગ પાડી શકાતો નથી, અને એ રીતે જ એક ડિપ્લોયમેન્ટ કોઈપણ અલગતા વિના પૂરું થાય છે.

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

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

દરેક સરનામાને એવી ઓળખ આપો જે સ્વતંત્ર રીતે રદ થઈ શકે

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

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

નકાર ત્યાં મૂકો જ્યાં પેકેટ ટનલ પાર કરે છે

જે ગેટવે WireGuard ટ્રાફિક ફોરવર્ડ કરે છે ત્યાં બે નિયમ કેસ આવરી લે છે: સેવા બ્લોકને મંજૂરી આપો, પછી ક્લાયન્ટ બ્લોકનો બાકીનો ભાગ છોડી દો. ઇન્ટરફેસ જોડી સરનામાં જેટલી જ મહત્વની છે, કારણ કે ફક્ત ગંતવ્ય પર મેળ ખાવાથી LANમાંથી આવતો ટ્રાફિક પણ પકડાય છે. મંજૂરી પહેલા મૂલવાય તે માટે તેમને તે ક્રમમાં લોડ કરો.

nftables સાથે જોડી હાલના inet filter કોષ્ટકમાં જાય છે, પહેલા મંજૂરી અને પછી છોડી દેવું. બંને મેળ સરનામાંની સાથે ઇન્ટરફેસ જોડી પણ પિન કરે છે.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

લોડ કર્યા પછી એક્ઝિટ સ્થિતિ પર ભરોસો કરવાને બદલે શૃંખલા ફરી વાંચો, અને બંને નિયમ તમે ઇચ્છેલા ક્રમમાં છે તેની ખાતરી કરો. IPv6 પૂલ માટે મળતા ip6 નિયમો ઉમેરો, નહીં તો ડ્યુઅલ-સ્ટેક ટનલ પર v4 જોડી ફક્ત શણગાર છે. જો સર્વર પાસે પહેલેથી મંજૂરી આપતી ફોરવર્ડ નીતિ હોય, તો શૃંખલાને સંપૂર્ણ બદલવાને બદલે છોડી દેવાનું ઉમેરો.

જ્યારે OpenVPN પર client-to-client સક્રિય હોય, ત્યારે આ ફોરવર્ડ નિયમો પીઅર ટ્રાફિક સાથે ક્યારેય મળતા નથી અને નકાર ડિમનના પોતાના નિયંત્રણોમાં જીવવો જોઈએ. હોસ્ટને સંબોધિત ટ્રાફિક માટે કર્નલ નિયમો રાખો, પણ તેમને અલગતા નિયંત્રણ તરીકે ગણો નહીં.

નકાર ક્લાયન્ટમાંથી સિદ્ધ કરો, સર્વરમાંથી નહીં

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

મંજૂર ક્લાયન્ટમાંથી ખાતરી કરો કે સેવા તેના પોર્ટ પર જવાબ આપે છે. તે જ ક્લાયન્ટમાંથી પીઅર સરનામું અજમાવો અને નકારને બદલે શાંત છોડી દેવાની અપેક્ષા રાખો:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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