Proxmox પર LXC કે VM માં WireGuard: તે ક્યાં ચાલવું જોઈએ?
WireGuard Proxmox યજમાન પર, કન્ટેનરમાં અથવા VM માં ચાલી શકે છે. નિર્ણાયક પરિબળો કર્નલની માલિકી, ઇન્ટરફેસ નિયંત્રણ અને પુનઃપ્રાપ્તિ છે.
WireGuard ને તેના ઇન્ટરફેસની માલિકી માટે બરાબર એક કર્નલની જરૂર છે, અને એ હકીકત પ્રદર્શન વાતચીતમાં આવે તે પહેલાં Proxmox પ્લેસમેન્ટની મોટાભાગની ચર્ચા ઉકેલે છે. LXC કન્ટેનર યજમાન કર્નલનું નેમસ્પેસ દૃશ્ય છે, જ્યારે VM પોતાનું કર્નલ બૂટ કરે છે. તેથી ઉપયોગી પ્રશ્ન એ નથી કે કયો વિકલ્પ હલકો છે, પણ એ કે તમે કયું કર્નલ બદલવા તૈયાર છો અને કયા પુનઃપ્રાપ્તિ માર્ગ સાથે જીવી શકો છો. તેનો જવાબ આપો, અને યજમાન, કન્ટેનર કે VM ની પસંદગી સામાન્ય રીતે જાતે જ થઈ જાય છે.
LXC મહેમાન યજમાન કર્નલની અંદર કામ કરે છે
કન્ટેનરની અંદર wireguard-tools ઇન્સ્ટોલ કરવાથી તમને નિયંત્રણ કાર્યક્રમ મળે છે, ખાનગી કર્નલ નહીં. તમે બનાવેલું wg0 ઇન્ટરફેસ યજમાનના નેટવર્ક સ્ટેકમાં નોંધાય છે અને યજમાનની મોડ્યુલ યાદીમાં દેખાય છે. તેથી કન્ટેનર બધી પેકેજ ચકાસણી પાસ કરી શકે અને તેમ છતાં પહેલા wg આદેશમાં નિષ્ફળ જાય, જ્યારે યજમાન કર્નલમાં એ મોડ્યુલ ન હોય. અને Proxmox કન્ટેનર સંદર્ભ એ વહેંચાયેલા કર્નલ મોડેલનું દસ્તાવેજીકરણ કરે છે, સાથે તમે જે નેમસ્પેસ અને વિશેષાધિકાર સીમાઓમાં કામ કરો છો તે પણ.
સત્તા એ બીજી મર્યાદા છે. ઇન્ટરફેસ ઉપર લાવવા અને તેના પર સરનામાં જોડવા માટે તેની માલિકી ધરાવતા નેમસ્પેસની અંદર નેટવર્ક વ્યવસ્થાપન અધિકારો ની જરૂર પડે છે, અને અવિશેષાધિકૃત કન્ટેનર એ અધિકારોને સીધા રાખવાને બદલે તેના વપરાશકર્તા નેમસ્પેસ દ્વારા મેપ કરે છે. પ્રથમ જવાબ તરીકે કદી પૂર્ણ વિશેષાધિકાર તરફ ન જાઓ; કન્ટેનરને ખરેખર શું કરવાનું કહેવાય છે તે જુઓ, પછી તે આપો.
યજમાન કર્નલ પણ વહેંચાયેલી નિર્ભરતા છે. Proxmox કર્નલ અપડેટ એકસાથે દરેક કન્ટેનર હેઠળ WireGuard નું અમલીકરણ બદલે છે, જે ત્યાં સુધી અનુકૂળ છે જ્યાં સુધી અપડેટ અને કન્ટેનરની અપેક્ષાઓ સહમત ન થાય.
યજમાન, કન્ટેનર, VM: દરેક પ્લેસમેન્ટ ખરેખર શું ધરાવે છે
યજમાન પર પ્લેસમેન્ટ VPN ને હાઇપરવાઇઝરના પોતાના નેટવર્કમાં મૂકે છે. રૂટ, ફાયરવોલ નિયમો અને ટનલ યજમાન પુનઃપ્રાપ્તિનો ભાગ બની જાય છે, અને ત્યાંની ભૂલ સંચાલન ઇન્ટરફેસને પણ લઈ જઈ શકે છે. કન્સોલ દ્વારા પહોંચી શકાય તેવા યજમાન પર માળખાગત રૂટિંગ માટે આ સ્વીકાર્ય છે, અને આઉટ-ઓફ-બેન્ડ ઍક્સેસ વગરના દૂરના બોક્સ પર પીડાદાયક.
કન્ટેનર સેવાને પેકેજ્ડ અને પુનઃશરૂ કરી શકાય તેમ રાખે છે, જ્યારે હજી યજમાન કર્નલ ઉધાર લે છે. તે જાણી જોઈને વહેંચાયેલા કર્નલની સેવા માટે યોગ્ય છે અને પુનઃનિર્માણ માટે તમને નાનું એકમ આપે છે. તે સ્વતંત્ર કર્નલ આપતું નથી, તેથી ચોક્કસ મોડ્યુલ બિલ્ડની જરૂર હોય તેવું કંઈપણ આ વિકલ્પથી દૂર સંકેત કરે છે.
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM વધુ મેમરી અને પેચ કરવા માટે બીજી સિસ્ટમનો ખર્ચ કરે છે, અને બદલામાં ટનલને પોતાનું કર્નલ, પોતાનું રૂટિંગ ટેબલ અને સ્નેપશોટ સીમા મળે છે. જ્યારે ખરાબ ફેરફાર પછી તમે VPN ને પાછું ફેરવો છો, ત્યારે એ સ્નેપશોટ વધારાના ભારને લાયક છે.
ત્રણ શરતો જે તમારા વતી પસંદ કરે છે
જો ટનલને એવી કર્નલ આવૃત્તિ કે WireGuard સુવિધાની જરૂર હોય જે Proxmox યજમાન પૂરી પાડતું નથી, તો અહીં થોભો અને VM વાપરો. કન્ટેનરમાં નવું કર્નલ ઇન્સ્ટોલ કરી શકાતું નથી, અને એક મહેમાનને સંતોષવા માટે હાઇપરવાઇઝર કર્નલ બદલવો ન જોઈએ.
જો ટનલ સાઇટનું ગેટવે હોય વાસ્તવિક LAN પ્રીફિક્સ માટે, તો પૂછો કે પરત માર્ગની માલિકી પહેલેથી કોની પાસે છે. કન્ટેનર ટ્રાફિક રૂટ કરી શકે છે, પણ તેના ઇન્ટરફેસ યજમાનના સ્ટેકમાં બેસે છે, તેથી યજમાન આખરે રૂપરેખાંકનનો ભાગ વહે છે, તમે યોજના બનાવી હોય કે નહીં. યજમાન પર પ્લેસમેન્ટ આમાં પ્રામાણિક છે; કન્ટેનરમાં પ્લેસમેન્ટ ઘણી વાર નથી.
પછી ભૂલની અસરની ત્રિજ્યા તોળો. કન્ટેનર ફરી શરૂ કરવું સસ્તું છે, VM સ્નેપશોટ પુનઃસ્થાપિત કરવો અનુમાનિત છે, અને યજમાન નેટવર્કિંગ સુધારવા ભૌતિક કે કન્સોલ ઍક્સેસની જરૂર પડી શકે છે. સાચી પસંદગી એ છે જેનો સૌથી ખરાબ કિસ્સો તમે જે કલાકે બને ત્યારે ખરેખર પુનઃપ્રાપ્ત કરી શકો.
ચોથો પ્રશ્ન ભાગ્યે જ નિર્ણાયક હોય છે પણ કહેવા જેવો છે: યજમાન પર બીજું કંઈ ટનલ ઇન્ટરફેસ જોવાની જરૂર ધરાવે છે? જો હા, તો યજમાન પર કે કન્ટેનરમાં પ્લેસમેન્ટ એ દૃશ્યતાને સ્થાનિક રાખે છે, જ્યારે VM તમને મહેમાન અને યજમાન વચ્ચે રૂટ કરવા ફરજ પાડે છે.
ટ્રાફિક તેમાંથી પસાર કરતા પહેલા પ્લેસમેન્ટ સાબિત કરો
ઇન્સ્ટોલ થયા પછી, ખાતરી કરો કે કયું કર્નલ ખરેખર ઇન્ટરફેસને સેવા આપે છે અને કન્ટેનરને તે રાખવા માટે પૂરતી સત્તા મળી છે કે નહીં:
$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0પછી યજમાનથી ફોરવર્ડિંગ બાજુ ચકાસો, કારણ કે માત્ર હેન્ડશેક સાબિત કરે છે કે ટનલ ઉપર છે. ક્લાયન્ટ સરનામા માટે ip route get વાપરો અને ખાતરી કરો કે આગળનો હોપ અને ઇન્ટરફેસ ડિઝાઇન સાથે મેળ ખાય છે, અને દૂરની બાજુએ પરત માર્ગ અસ્તિત્વમાં છે.
જમાવટને લેખિત માલિક સાથે છોડો: કયું કર્નલ અમલીકરણ વહે છે, કયું નેમસ્પેસ ઇન્ટરફેસ ધરાવે છે, અને ગેટવેને કયા પ્રીફિક્સ ફોરવર્ડ કરવાની પરવાનગી છે. એ એક વાક્ય ત્રણ પ્લેસમેન્ટની કોઈપણ બેન્ચમાર્ક સરખામણી કરતાં વધુ ઘટનાઓ અટકાવે છે.