ટનલ દ્વારા દૂરના /24 સુધી પહોંચવું: NETMAP, DNAT કે રૂટ?
NETMAP સાથે આખું પ્રીફિક્સ મેપ કરો, દરેક હોસ્ટ માટે DNAT નિયમો ઉમેરો અથવા અસલી રેન્જ રૂટ કરો, અને દૂરની બાજુએ શું દેખાવું જોઈએ તથા કોણ ટ્રાફિક શરૂ કરી શકે તેના આધારે નિર્ણય કરો.
ટનલના છેડા પાછળની સબનેટ સુધી ત્રણ રીતે પહોંચી શકાય છે, અને એક મિનિટની હકીકત એકઠી કરવાથી સામાન્ય રીતે બે બાદ થાય છે. હકીકતો એ છે કે ત્યાંના સર્વરોએ વપરાશકર્તાઓને અલગ પાડવા પડે છે કે નહીં, ત્યાંથી કોઈ ક્યારેય તમારી રેન્જ તરફ ડાયલ કરશે કે નહીં, અને દૂરના છેડાના રાઉટરને કોણ સંપાદિત કરી શકે. આ ત્રણનો જવાબ આપો અને ડિઝાઇન જાતે પસંદ થઈ જશે. બાકીનું ધારે છે કે તમે છેડો ચલાવો છો અને તેનું ફાયરવોલ સંપાદિત કરી શકો છો.
ત્રણ વિકલ્પો, અને દરેક ખરેખર શું બદલે છે
પ્રીફિક્સ મેપિંગ, પ્રતિ-હોસ્ટ DNAT અને રૂટ કરેલું પ્રીફિક્સ — બધા પેકેટને એ જ બે રેન્જ વચ્ચે ખસેડે છે, પણ જુદી જુદી વસ્તુઓ બદલે છે. મેપિંગ એક બનાવટી એલિયાસ રેન્જ શોધે છે અને ઉડાન દરમિયાન સરનામાંઓને ગાણિતિક રીતે ફરી લખે છે. પ્રતિ-હોસ્ટ નિયમો પણ ફરી લખે છે, ફક્ત દરેક લક્ષ્ય હાથે નામ આપવામાં આવે છે. રૂટ કરેલું પ્રીફિક્સ કંઈ ફરી લખતું નથી: પેકેટ અસલી સરનામાં રાખે છે અને બંને છેડા સહમત થાય છે કે એ સરનામાં ક્યાં રહે છે.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
બાદબાકી દૂરની બાજુથી શરૂ કરો, જ્યાં મર્યાદાઓ બદલવી સૌથી અઘરી છે. જો ત્યાંનું સર્વર ક્લાયન્ટ સરનામાં લોગમાં લખે, તેમને મંજૂર યાદી સામે ચકાસે અથવા બીજી સિસ્ટમને સોંપે, તો સ્રોતનું ભાષાંતર તેની એકમાત્ર ઓળખનો નાશ કરે છે. જો દૂરની બાજુએ પણ ડાયલ કરવું પડે, તો ભાષાંતર સંપૂર્ણપણે બાદ થાય છે, કારણ કે ત્યાં કોઈને ખબર નથી કે એલિયાસ અસ્તિત્વમાં છે. ફક્ત ત્યારે જ જ્યારે દૂરની બાજુ ફક્ત વિનંતીઓનો જવાબ આપે છે, સસ્તા વિકલ્પો સુરક્ષિત બને છે.
પ્રીફિક્સ જોડીઓ, અને કેમ માપ સરખા હોવા જોઈએ
NETMAP એ nat ટેબલનું લક્ષ્ય છે જે સમાન લંબાઈની પ્રીફિક્સ જોડી પર કામ કરે છે. તેની અંદર પ્રતિ-સરનામું ટેબલ નથી: તે પ્રીફિક્સ દૂર કરે છે, હોસ્ટ બિટ્સ રાખે છે અને તેમને નવા પ્રીફિક્સ સાથે ફરી જોડે છે, તેથી /24 એ /24 પર મેપ થાય છે અને ક્યારેય /25 પર નહીં. સ્થાન દિશા નક્કી કરે છે: PREROUTING માં લક્ષ્ય મેળ પેકેટ ક્યાં જાય છે તે ફરી લખે છે, અને POSTROUTING માં સ્રોત મેળ તે ક્યાંથી આવ્યું તે ફરી લખે છે.
192.168.2.17 પરનું હોસ્ટ તમારા ક્લાયન્ટને 10.50.1.17 તરીકે દેખાય છે, અને છેલ્લું ઓક્ટેટ સુશોભન નથી — તે બંને બાજુએ સમાન સંખ્યા છે. કાલે 192.168.2.40 પર હોસ્ટ ઉમેરો અને તેનું એલિયાસ 10.50.1.40 થશે, કોઈ નિયમ સંપાદિત કરવાની જરૂર વગર.
ક્લાયન્ટને હજુ પણ એલિયાસ રેન્જ માટે તમારા બોક્સ તરફ ઇશારો કરતો રૂટ જોઈએ છે, સિવાય કે એલિયાસ એવી સબનેટમાં આવે જે તેઓ પહેલેથી પહોંચે છે. ગેટવેને એલિયાસ માટે રૂટની જરૂર નથી, કારણ કે લક્ષ્ય ભાષાંતર રૂટ શોધ પહેલાં PREROUTING માં ચાલે છે. ફોરવર્ડિંગ પણ ચાલુ હોવું જોઈએ, નહીં તો કર્નલ ફરી લખ્યા પછી પેકેટ કાઢી નાખે છે. નીચેની ત્રણ આજ્ઞાઓ Debian શૈલીના ગેટવે પર આખું સેટઅપ છે, જ્યાં ક્લાયન્ટ br0 પર, એલિયાસ 10.50.1.0/24 પર અને ટનલ tun0 પર છે.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEજવાબે પોતાનો પરત માર્ગ શોધવો પડશે
લક્ષ્ય ફરી લખવું ફક્ત નક્કી કરે છે કે પેકેટ ક્યાં પહોંચાડવું. દૂરની બાજુના સર્વરે હજુ પણ એવા સરનામાનો જવાબ આપવો પડે છે જ્યાં તે પહોંચી શકે, અને તે ગોઠવવાની બે રીતો છે. સ્રોતનું ભાષાંતર કરો જેથી જવાબો તમારા બોક્સ પર પાછા આવે, અથવા સ્રોતને અકબંધ રાખો અને દૂરની બાજુને ક્લાયન્ટ રેન્જનો રૂટ આપો.
બહાર જતા માર્ગ પર માસ્કરેડિંગ ટૂંકો માર્ગ છે: POSTROUTING માં એક નિયમ અને દૂરની બાજુ તમારું ટનલ સરનામું જુએ છે, તેથી તેને પોતાના રૂટની જરૂર નથી. કિંમત એ છે કે બધા વપરાશકર્તા એક જ સરનામામાં ભળી જાય છે, અને પ્રતિ-વપરાશકર્તા લોગ અર્થ ગુમાવે છે. સ્રોતને અકબંધ રાખવાથી એ માહિતી રહે છે, પણ પછી દૂરના સાઇટે ક્લાયન્ટ રેન્જના જવાબો ટનલ દ્વારા પાછા મોકલવા પડે છે. એક OpenVPN સર્વર પર તે છે મોકલેલું push "route 10.50.9.0 255.255.255.0", ઉપરાંત એક લીટી route 192.168.2.0 255.255.255.0.
ખર્ચાળ નિષ્ફળતા એ છે કે દરેકનું અડધું કરવું. જો તમે થોડો ટ્રાફિક માસ્કરેડ કરો જ્યારે દૂરની બાજુ બીજા ટ્રાફિક માટે પરત રૂટ પણ ધરાવે છે, તો જવાબો એવા ઇન્ટરફેસ પર આવે છે જ્યાં કનેક્શન-ટ્રેકિંગ એન્ટ્રી ક્યારેય જોઈ નથી. ક્લાયન્ટ એ વિનંતી માટે સમયસમાપ્તિ જણાવે છે જે સર્વરે સેવા આપેલી તરીકે લોગ કરી હતી. પ્રવાહની બંને દિશાઓએ એક જ netfilter ઇન્સ્ટન્સ પાર કરવો પડે છે: એક ગેટવે ભાષાંતર કરે છે, બે ફાયરવોલ ક્રમમાં નહીં.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nએન્ટ્રી બંને દિશામાં વાંચો: મૂળ ટ્યુપલ લક્ષ્ય પર તમારું એલિયાસ રાખે છે, જ્યારે જવાબ ટ્યુપલ અસલી સરનામું ધરાવે છે. જો જવાબ ટ્યુપલ ગેરહાજર હોય, તો સમસ્યા નિયમમાં નહીં, પરત માર્ગમાં છે. જો PREROUTING કાઉન્ટર ક્યારેય ખસ્યા ન હોય, તો પેકેટ ક્યારેય એ હૂક સુધી પહોંચ્યું જ નથી.
અથડામણો અને પહેલાં ચાલતી શોધ
બે જુદી રેન્જ અથડાઈ શકે છે અને બંને નિષ્ફળતા ખરાબ નિયમને બદલે તૂટેલી ટનલ જેવી લાગે છે. તમે બનાવો છો તે એલિયાસ આખા માર્ગ પર વણવપરાયેલું હોવું જોઈએ, અને દૂરની બાજુની અસલી રેન્જ તમારા નેટવર્ક પર પહેલેથી હોવી ન જોઈએ. નકલ ખોટા હોસ્ટ તરફ અવારનવાર ટ્રાફિક ઉત્પન્ન કરે છે, જે નકારેલા કનેક્શન કરતાં નિદાન કરવું અઘરું છે. નિયમ ઉમેરતા પહેલાં રૂટિંગ ટેબલને પૂછો.
ગેટવે પર, ip route get 192.168.2.17 ટનલ ઉપકરણનું નામ આપવું જોઈએ; સ્થાનિક બ્રિજનો અર્થ છે કે દૂરની રેન્જ છાયામાં છે અને કોઈ nat નિયમ તેને સુધારશે નહીં. જો તમારું નેટવર્ક પહેલેથી 192.168.2.0/24 વાપરે છે, તો અથડામણ પર મેપિંગ ચઢાવવાને બદલે દૂરની સાઇટને ફરી નંબર આપો.
અસલી ક્લાયન્ટથી પરીક્ષણ, પછી જાળવણી
એવી મશીનથી પરીક્ષણ કરો જે ખરેખર એલિયાસ વાપરશે, ગેટવેથી નહીં, કારણ કે સ્થાનિક રીતે બનેલો ટ્રાફિક ક્યારેય એ જ રીતે PREROUTING પાર કરતો નથી. એલિયાસવાળા એક હોસ્ટ સાથે કનેક્શન ખોલો અને કાઉન્ટર અને conntrack એન્ટ્રી સાથે દેખાતા જુઓ, પછી બંધ કરો અને ખાતરી કરો કે એન્ટ્રી જતી રહે છે. જૂની એન્ટ્રી અડધું-ખુલ્લા કનેક્શન તરફ ઇશારો કરે છે, જેનો સામાન્ય અર્થ છે કે જવાબ ક્યારેય પાછો આવ્યો નથી.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17બે કે ત્રણ સફળ કનેક્શન ગણિત સાબિત કરે છે, પણ સ્થિરતા કે આગલા એન્જિનિયર વિશે કંઈ કહેતા નથી. નિયમો ત્યાં સાચવો જ્યાં બૂટ પ્રક્રિયા તેમને વાંચે છે, જે Debian અને Ubuntu પર iptables-save > /etc/iptables/rules.v4 અને netfilter-persistent સક્રિય એમ અર્થ થાય છે. રીબૂટ પર અદૃશ્ય થતું મેપિંગ કરતાં ન હોવું સારું છે, કારણ કે વિક્ષેપ તાજેતરના કોઈ ફેરફાર વગર આવે છે જેને દોષ આપી શકાય.
નિયમોની બાજુમાં એક નોંધ છોડો: એલિયાસ રેન્જ, અસલી રેન્જ, જોડીનું કારણ અને કઈ બાજુ શરૂ કરી શકે. એ નોંધ ડિઝાઇનને એવા નિયમોના ઢગલાથી અલગ પાડે છે જે કોઈ કાઢવાની હિંમત કરતું નથી. તે પછીના પ્રશ્નનું પણ નિરાકરણ કરે છે, જ્યારે દૂરની સાઇટ હોસ્ટ ઉમેરે છે અને કોઈએ ગોઠવ્યું ન હોય એવું સરનામું પહેલેથી જવાબ આપે છે. જો નોંધ કહે કે દૂરની બાજુને પરત રૂટ જોઈએ છે, તો આગલી વ્યક્તિ જાણે છે કે માસ્કરેડ નિયમ કાઢવાથી કનેક્ટિવિટી તૂટે છે. અહીં દસ્તાવેજીકરણ સસ્તું છે; રાત્રે ત્રણ વાગ્યે NAT નિર્ભરતા ફરી શોધવી નહીં.