બીજું NAT ઉમેરતા પહેલા ખાનગી LAN વચ્ચે રૂટિંગ કરો

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

ડિઝાઇન નક્કી કરતી ત્રણ શરતો

પ્રથમ શરત એડ્રેસ સ્પેસ છે. જો બંને LAN એક જ RFC 1918 બ્લોક વાપરે છે, તો રૂટિંગ તેમને અલગ પાડી શકતું નથી અને અનુવાદ વૈકલ્પિકને બદલે અનિવાર્ય બને છે. બીજી રિટર્ન પાથ છે: A થી B સુધીનો રૂટ ત્યારે જ નકામો છે જ્યારે B ને પણ A ના LAN સુધી કેવી રીતે પહોંચવું તે ખબર ન હોય, અને અસમમિત જ્ઞાન એ સૌથી સામાન્ય કારણ છે કે રૂટેડ ડિઝાઇન શાંતિથી જવાબો છોડી દે છે.

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

જ્યારે ત્રણેય એક જ દિશામાં ઈશારો કરે ત્યારે જ સરળ ડિઝાઇન જીતે છે. જ્યારે તેમાંથી એક નિષ્ફળ જાય, ત્યારે તે શરતને અનુવાદથી ઢાંકવાને બદલે સ્પષ્ટ રીતે સુધારો, કારણ કે NAT નિષ્ફળતાને છુપાવે છે, ઉકેલતું નથી.

ટ્રાન્ઝિટ નેટવર્ક પર રૂટ યોજના બનાવો

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

ફાયરવોલ A 10.30.0.0/24 પર સેવા આપે છે અને ફાયરવોલ B 10.40.0.0/24 પર, જ્યારે બે ટ્રાન્ઝિટ એડ્રેસ 192.0.2.0/24 પર છે. દરેક LAN હોસ્ટ પોતાની સ્થાનિક ફાયરવોલને ગેટવે તરીકે રાખે છે, તેથી એકમાત્ર નવી સ્થિતિ દરેક બાજુ એક રૂટ છે. Linux આધારિત ફાયરવોલ પર એ જ યોજના આવી દેખાય છે, અને ફોરવર્ડિંગ સક્ષમ હોવું જોઈએ, નહીં તો રૂટ ઉકેલાશે જ્યારે પેકેટ છોડી દેવાશે.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

ફિલ્ટરિંગને અનુવાદથી અલગ રાખો

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

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

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

જ્યારે NAT જ પ્રામાણિક જવાબ છે

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

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

જ્યારે ટ્રાન્ઝિટ પોતે ખોટી ધારણા છે

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

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