ફક્ત પોર્ટ 25 ટનલમાં મોકલો, હોસ્ટ નહીં

Linux હોસ્ટ પોતાનું જ SMTP ટનલ દ્વારા મોકલે તે પહેલાં ચાર વસ્તુઓ મેળવવી પડે: સમર્પિત ટેબલમાં એક રૂટ, ટ્રાફિક પસંદ કરતો નીતિ-નિયમ, પીઅર સ્વીકારશે તેવું સ્રોત સરનામું, અને અસમાનતાનો સામનો કરતો પરત માર્ગ. દરેક અલગ રૂપરેખાંકન છે, દરેકની પોતાની નિષ્ફળતાની રીત છે. નીચેનો ક્રમ એ છે જે નિષ્ફળતાને ખરેખર ખોટા ભાગ તરફ દર્શાવે છે. આ પોર્ટ-વિશિષ્ટ રૂટિંગ કાર્ય છે, VPN ડિફોલ્ટ રૂટની વિનંતી નહીં.

પોર્ટ નિયમ ડિફોલ્ટ રૂટ નથી

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

wg-quick ની બે સેટિંગ્સ નીતિનો ભાગ નહીં, પૂર્વશરતો છે. AllowedIPs = 0.0.0.0/0 પીઅરને મનસ્વી IPv4 લક્ષ્યો લઈ જવા દે છે, અને Table = off તે પ્રીફિક્સ માટે wg-quick ને પોતાનો ડિફોલ્ટ રૂટ સ્થાપિત કરતું અટકાવે છે. આ સૂચનાઓને પોતાની રૂટ નીતિ લાગુ કરતા મેનેજર સાથે ન ભેળવો, કારણ કે બંને મુખ્ય ટેબલ કોનું છે તે અંગે સંમત નહીં થાય.

રૂટ, સિલેક્ટર અને ગાર્ડ લખો

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

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo નિયમને સ્થાનિક ઉદ્ભવના ટ્રાફિક સુધી મર્યાદિત કરે છે, અને ipproto tcp dport 25 જોડાણની દિશા ઓળખે છે; ip-rule સંદર્ભ બંને સિલેક્ટરોનું દસ્તાવેજીકરણ કરે છે. તે વર્તમાન કર્નલ અને iproute2 આવૃત્તિઓમાં હાજર છે, અને જૂની સિસ્ટમમાં નિયમ સંપૂર્ણપણે નકારવામાં આવે છે, જે લોડ થઈને કંઈપણ સાથે ન મળતા નિયમ કરતાં વધુ સ્પષ્ટ નિષ્ફળતા છે.

આગલી પ્રાયોરિટીનો unreachable નિયમ ગાર્ડ છે. તેના વગર, ટેબલ 51825 માં ગેરહાજર રૂટ સામાન્ય ડિફોલ્ટમાં પડી જાય છે, અને ટનલ બંધ થયા વખતે મેલ ભૌતિક લિંક પરથી નીકળી જાય છે, જે નીતિ રોકવા માટે બનાવવામાં આવી હતી તે બરાબર એ જ કિસ્સો છે.

સ્રોત સરનામું મેળ ખાવું જોઈએ

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

ગેટવે પર, ક્લાયન્ટના પીઅરે ખરેખર મળતા સ્રોતને અધિકૃત કરવો પડે, જે પહોળા લક્ષ્ય પ્રીફિક્સને બદલે 10.77.0.2/32 છે. ક્લાયન્ટના 0.0.0.0/0 ને દરેક ગેટવે પીઅરમાં નકલ કરવાથી કોણ કયો ટ્રાફિક ધરાવે છે તે ગૂંચવાય છે. ગેટવેને ફોરવર્ડિંગ, પ્રવાહને મંજૂરી આપતી ફાયરવોલ નીતિ, અને પરત માર્ગની પણ જરૂર છે, જેમાં અપસ્ટ્રીમ ખાનગી ટનલ સરનામું રૂટ કરી શકે નહીં ત્યારે ઇગ્રેસ અનુવાદનો સમાવેશ થાય છે.

પરત માર્ગ તપાસો, પછી ટકાઉપણું

કંઈપણ પર ભરોસો કરતા પહેલાં લુકઅપ વાંચો, કારણ કે તે બતાવે છે કે દરેક દિશાને કયું ટેબલ અને કયો સ્રોત મળે છે. પોર્ટ 25 પર એક લક્ષ્ય અને પોર્ટ 443 પર એ જ લક્ષ્ય પૂરતા છે:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

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

જ્યાં અસમાન રૂટિંગ અધિકૃત છે, ત્યાં net.ipv4.conf.wg0.rp_filter=2 દ્વારા ઇન્ટરફેસ-મર્યાદિત ઢીલી સ્થિતિ યોગ્ય હોઈ શકે, અને પહેલા all અને ઇન્ટરફેસ મૂલ્યોની અસરકારક મહત્તમ તપાસવી યોગ્ય છે. શોર્ટકટ તરીકે માન્યતા વૈશ્વિક રીતે બંધ ન કરો. પછી ટેબલ, પ્રાયોરિટીઓ અને ગાર્ડ રૂપરેખાંકન ધરાવનારને સોંપો, અને ફરી જોડાયા પછી નવા જોડાણો ખોલીને ખાતરી કરો કે પસંદગી હજી ટકે છે. ધ્યાનમાં રાખો કે સ્થાનિક SMTP શ્રોતાના જવાબો સ્રોત પોર્ટ 25 વહન કરે છે, લક્ષ્ય પોર્ટ 25 નહીં, જે અલગ નીતિ પ્રશ્ન છે.