બ્રિજ વિના TAP: રાઉટેડ અપલિંક સાથેનું વર્ચ્યુઅલ સેગમેન્ટ
TAP ઉપકરણ એ Ethernet સેગમેન્ટ છે, બ્રિજ નહીં. તેને સરનામું આપો, તેની અને ઓફિસ પ્રીફિક્સ વચ્ચે રાઉટ કરો, અને બ્રોડકાસ્ટ વ્યાપ જાણી જોઈને રાખો.
TAP Ethernet ફ્રેમ ઓપરેટિંગ સિસ્ટમને સોંપે છે, જે મોટાભાગની રિમોટ-એક્સેસ ડિઝાઇનને જરૂર હોય તેનાથી વધુ ક્ષમતા અને બ્રિજથી ઓછું છે. કર્નલ તેને સરનામું આપી શકે, તેમાંથી રાઉટ કરી શકે અને કોઈ ભૌતિક સેગમેન્ટમાં જોડ્યા વિના તેના પર ફાયરવોલ મૂકી શકે. આ ગોઠવણી પહેલા સમજવા જેવી છે: એક અલગ વર્ચ્યુઅલ Ethernet સેગમેન્ટ જેનો સર્વર વાસ્તવિક LAN તરફ રાઉટર તરીકે કામ કરે છે. તે ટનલની અંદર બીજા સ્તરનું વર્તન અને બહાર સામાન્ય IP ફોરવર્ડિંગ આપે છે, જે બે અલગ વચનો છે. બાકીનું બાંધકામ, રૂટ, પાછા ફરવાનો માર્ગ અને રોલબેક છે.
અલગ સેગમેન્ટ બનાવો
લિનક્સમાં ઇન્ટરફેસ ત્રણ આદેશ લે છે: તેને બનાવો, તેને ઉપર કરો, તમે ધારેલા સેગમેન્ટની અંદર તેને સરનામું આપો. ઓફિસ LAN સાથે અથડાય નહીં એવું પ્રીફિક્સ પસંદ કરો અને તેને લખી રાખો, કારણ કે અથડામણ ત્યાં સુધી અદૃશ્ય છે જ્યાં સુધી એવો હોસ્ટ જવાબ ન આપે જે અસ્તિત્વમાં ન હોવો જોઈએ.
ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0
અહીં કંઈ પણ બ્રિજ માગતું નથી, અને પછીથી એક ઉમેરવાથી કંઈ રોકતું નથી. કર્નલ TUN/TAP દસ્તાવેજીકરણ ઇન્ટરફેસનું જ વર્ણન કરે છે; બ્રિજ સભ્યપદ અને ફોરવર્ડિંગ નીતિ એ અલગ નિર્ણયો છે જે તમે પછી લો છો.
સીમા પાર રાઉટ કરો
ફોરવર્ડિંગ સક્ષમ કરો, ફોરવર્ડ ચેઇનમાં બંને પ્રીફિક્સને મંજૂરી આપો, અને LAN રાઉટરને આગળના હોપ તરીકે રાખીને ઓફિસ પ્રીફિક્સ તરફ રૂટ ઉમેરો. પછી VPN બાજુ ઓફિસ તરફનું ટ્રાફિક પોતાના ગેટવે તરીકે સર્વરને મોકલે છે, અને સર્વર તે પેકેટોને બ્રિજ તરીકે નહીં, પોતાના તરીકે ફોરવર્ડ કરે છે. ફોરવર્ડિંગ બંધ હોય એવું TAP ઇન્ટરફેસ એ સેગમેન્ટ છે જે સ્થાનિક રીતે જવાબ આપે છે અને તેની બહાર કંઈ પહોંચતું નથી, જે સામાન્ય અડધું પૂરું થયેલી સ્થિતિ છે. પછીથી બંને બાજુ ઇન્ટરફેસ કાઉન્ટર તપાસો, કારણ કે LAN બાજુ પર સ્થિર ટ્રાન્સમિટ કાઉન્ટર સાથે વધતું રિસીવ કાઉન્ટર એટલે ખરાબ રૂટ નહીં, ફોરવર્ડ ચેઇનમાં ડ્રોપ.
રૂટ અને ફાયરવોલ નિયમને એક જ ફેરફાર તરીકે લખો, કારણ કે દરેક એકલું એવી સ્થિતિ ઉત્પન્ન કરે છે જે ક્લાયન્ટ બાજુથી રાઉટિંગ નિષ્ફળતા જેવી દેખાય છે.
પાછા ફરવાનો માર્ગ નક્કી કરો
કાં તો LAN રાઉટર VPN પ્રીફિક્સ તરફ પાછો રૂટ શીખે છે, અથવા સર્વર બહાર જતાં સ્રોત સરનામાંનું ભાષાંતર કરે છે. ભાષાંતર પાછા ફરવાનો માર્ગ સરળ બનાવે છે અને સ્રોતની ઓળખનો નાશ કરે છે, તેથી ગંતવ્ય લોગ તેની પાછળના દરેક ક્લાયન્ટ માટે સર્વરનું સરનામું દર્શાવશે. રાઉટેડ પ્રીફિક્સ ઓળખ જાળવે છે અને એવા સાધનો પર ફેરફાર માગે છે જે તમે કદાચ સંભાળતા ન હોવ.
ટાઇપ કરવા માટે કયું ઝડપી છે તેના આધારે નહીં, જાણી જોઈને પસંદ કરો. એક રાઉટેડ પ્રીફિક્સ સામાન્ય રીતે ભાષાંતર કરતાં સ્વચ્છ હોય છે, અને એક લેબ માટે સંચાલિત ન હોય એવા રાઉટરને નવું પ્રીફિક્સ શીખવવા કરતાં ભાષાંતર સામાન્ય રીતે સારું હોય છે.
બ્રોડકાસ્ટ વ્યાપ જાણી જોઈને રાખો
વર્ચ્યુઅલ સેગમેન્ટની અંદર DHCP, શોધ અને પડોશીની જાહેરાત સ્વિચ પર જેમ વર્તે છે તેમ વર્તે છે, કારણ કે તે એક જ લિંક છે. રાઉટેડ સીમાની બહાર તેઓ એમ કરતા નથી, તેથી ઓફિસ DHCP અને સેવા શોધને સ્પષ્ટ ડિઝાઇનની જરૂર છે, TAP તેમને સમાવે છે એવી ધારણાની નહીં. ઇન્ટરફેસનો પ્રકાર બીજે રહેતી સેવાઓ માટે રિલે નથી.
TAP પસંદ કરવાનું પ્રામાણિક કારણ આ છે: વર્ચ્યુઅલ સેગમેન્ટ પર કંઈકને લિંક-સ્થાનિક વર્તનની જરૂર છે. જો કંઈને જરૂર ન હોય, તો રાઉટેડ પ્રીફિક્સવાળું TUN ઉપકરણ નાનું છે, અને તૂટે ત્યારે સમજાવવાનું ઓછું રહે છે.
ચકાસો, પછી રોલબેક લખો
VPN ક્લાયન્ટમાંથી LAN રાઉટરને પિંગ કરો, હોસ્ટને પિંગ કરો, અને TCP પર મહત્ત્વની એક સેવા ખોલો. પછી કાઉન્ટર અને ફોરવર્ડ ચેઇન તપાસો, કારણ કે દૂરથી નીતિ-ડ્રોપ ગુમ થયેલા રૂટ જેવો જ દેખાય છે. રોલબેક બાંધકામનો ઊલટો છે અને શરૂ કરતાં પહેલાં ફેરફાર રેકોર્ડમાં હોવો જોઈએ: રૂટ દૂર કરો, સરનામું દૂર કરો, ઇન્ટરફેસ કાઢી નાખો.
જો જરૂરિયાત ખરેખર બે સાઇટ સુધી ફેલાતું એક Ethernet સેગમેન્ટ હોય, તો બ્રિજ પ્રામાણિક જવાબ છે અને અલગ અસર ત્રિજ્યાવાળી અલગ ડિઝાઇન. જો જરૂરિયાત પહોંચ હોય, તો રાઉટેડ અપલિંક સાથેનું અલગ સેગમેન્ટ પછીથી ઓછી સમજ સાથે કામ કરી દે છે.