એક NIC કે બે? VPN સર્વરનું ઇન્ટરફેસ લેઆઉટ કેવી રીતે નક્કી કરવું

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

તેને નક્કી કરતી ત્રણ શરતો

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

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

ત્રણમાંથી કોઈ પણ ચેસિસ પરના પોર્ટની સંખ્યા વિશે નથી. તે રાઉટિંગ, સરનામાંની માલિકી અને ડિઝાઇન ભૌતિક અલગીકરણ પર કેટલી આધાર રાખે છે તે વિશે છે.

બે એડેપ્ટર કાયદેસર પસંદગી રહે છે જ્યારે ભૌતિક ઝોન, અલગ અપલિંક, થ્રુપુટ કે આઉટ-ઓફ-બેન્ડ રિકવરી માર્ગ તેને ન્યાયી ઠેરવે. આ ચોક્કસ જરૂરિયાતો છે, અને કોઈ હાર્ડવેર ઓર્ડર કરે તે પહેલાં તે કહેવા યોગ્ય છે.

જ્યારે સેવા VPN હોસ્ટ પર ચાલે છે

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

તેમ છતાં બે વસ્તુ સાચી હોવી જોઈએ: સેવાએ એવા સરનામા પર સાંભળવું જોઈએ જ્યાં ટનલ પહોંચી શકે, અને હોસ્ટ ફાયરવોલે ટનલ ઇન્ટરફેસ પર આવતો ટ્રાફિક સ્વીકારવો જોઈએ. બંને નીચેના આદેશોમાં દેખાય છે.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

જ્યારે લક્ષ્ય LAN પર હોય

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

બંને જવાબ કાયદેસર છે અને બંને અલગ રીતે નિષ્ફળ જાય છે. પરત રૂટ ક્લાયન્ટનું મૂળ સરનામું લક્ષ્ય માટે દૃશ્યમાન રાખે છે, જે લોગ માટે સારું અને LAN સરનામાં ધારી લેતા ફાયરવોલ નિયમો માટે ખરાબ છે. અનુવાદ LANને સરળ રાખે છે અને લક્ષ્યથી ક્લાયન્ટની ઓળખ છુપાવે છે.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

શા માટે એલિયાસ બીજો ઝોન બનાવતું નથી

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

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

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

તમે મંજૂરી આપો તે ટ્રાફિક સામે લેઆઉટ ચકાસો

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

પછી ડિઝાઇન દસ્તાવેજનું આકૃતિ નહીં, વાસ્તવિક ઇન્ટરફેસ અને વાસ્તવિક કેપ્ચરની પુષ્ટિ કરો. નીચેના આદેશો બંને દૃશ્ય છાપે છે.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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