Linux પર IPsec વગર L2TP: xl2tpd, pppd અને NAT

સાદું L2TP એ લિફાફાની અંદરનું PPP છે, અને બીજું કંઈ નહીં. તે તમારા ફ્રેમ્સ વહન કરે છે; તેમને એન્ક્રિપ્ટ કરતું નથી અને બીજા છેડે કોણ બેઠું છે તે સાબિત કરતું નથી, તેથી લગભગ દરેક ડિપ્લોયમેન્ટ તેની નીચે IPsec નાખે છે. નગ્ન આવૃત્તિ ચલાવવાના પ્રામાણિક કારણો હજી પણ છે: લેબ બેન્ચ, માઇગ્રેશન પગલું, અથવા એવી લિંક જે પહેલેથી જ બીજા સુરક્ષિત માર્ગની અંદર છે.

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

ત્રણ ફાઇલો કામ વહેંચે છે

xl2tpd નિયંત્રણ કનેક્શન સમાપ્ત કરે છે અને દરેક સત્ર PPP ડેમનને સોંપે છે, તેથી રૂપરેખાંકન બે પ્રોગ્રામમાં વહેંચાયેલું રહે છે જે કદી એકબીજાની ફાઇલો વાંચતા નથી. સાંભળનાર /etc/xl2tpd/xl2tpd.conf માં, [lns default] વિભાગની અંદર રહે છે, જે સરનામા પૂલને ip range થી, સર્વર છેડાને local ip થી અને PPP ને સોંપણીને pppoptfile થી નામ આપે છે. require authentication = yes ચાલુ કરો, length bit અને flow bit સક્ષમ રાખો, અને એવો પૂલ પસંદ કરો જેનો હોસ્ટ પર બીજું કંઈ વાપરતું ન હોય.

PPP નીતિ એ ફાઇલની છે જે એ વિકલ્પ નામ આપે, સામાન્ય રીતે /etc/ppp/options.xl2tpd: auth, pap, chap અને mschap માટે નકાર, require-mschap-v2, 1460 નું MTU અને MRU, અને એવું DNS સરનામું જ્યાં લિંક ઉપર આવ્યા પછી ક્લાઇન્ટ પહોંચી શકે. ઓળખપત્રો ફરી ત્રીજી ફાઇલ છે, /etc/ppp/chap-secrets, જ્યાં બીજું ક્ષેત્ર LNS વિભાગના નામ સાથે મેળ ખાવું જોઈએ અને ચોથું ક્ષેત્ર પૂલમાંથી ચોક્કસ સરનામું પિન કરી શકે.

ટનલ કેમ જોડાય છે અને પછી અટકે છે

1500 બાઇટનો Ethernet ફ્રેમ એવા માર્ગમાં સમાતો નથી જે પહેલેથી જ પોતાના હેડરો પર બાઇટ્સ ખર્ચે છે. બહારનું IPv4 હેડર 20 લે છે, UDP 8, અને L2TP હેડર લગભગ 12, જે PPP અને તેના પેલોડ માટે 1460 છોડે છે. PPP માં એ નાની સંખ્યા જાહેર કરવી એ જ મોટા પેકેટોને ટુકડાઓમાં વિભાજિત થવાથી કે વચ્ચે ક્યાંક ચૂપચાપ પડી જવાથી રોકે છે.

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

એક પોર્ટ બે વાતચીત વહન કરે છે

UDP 1701 પ્રોટોકોલના બંને અડધા ભાગની નીચે બેસે છે, અને એ એક હકીકત સેટઅપના બીજા કોઈ પણ ભાગ કરતાં વધુ ફાયરવોલ નિયમો તોડે છે. પહેલાં નિયંત્રણ-કનેક્શનની શરૂઆતની વિનંતી અને તેનો જવાબ આવે છે; પછીની સત્ર વિનંતી અને પુષ્ટિ ઓળખકર્તા જોડી કરતાં વધુ કંઈ સ્થાપિત કરતી નથી. પછી PPP સંભાળ લે છે: લિંક નિયંત્રણ, પછી પ્રમાણીકરણ, પછી સરનામાં નક્કી કરવા IP નિયંત્રણ પ્રોટોકોલ. લોગમાં દરેક તબક્કાની પોતાની શબ્દાવલી છે, અને તેમાંથી કોઈ પોતાને L2TP નિષ્ફળતા તરીકે જાહેર કરતું નથી.

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

ટનલને ઉપયોગી બનાવવી: ફોરવર્ડિંગ અને NAT

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

સર્વર પર sysctl -w net.ipv4.ip_forward=1 થી ફોરવર્ડિંગ ચાલુ કરો, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE થી પૂલનું ભાષાંતર કરો, પછી -i ppp0 -o eth0 માટે FORWARD નિયમ વડે બહાર જતી ટનલ ટ્રાફિક અને અરીસા નિયમ સાથે -m state --state RELATED,ESTABLISHED વડે પાછી આવતી ટ્રાફિક સ્વીકારો. આ નિયમો રીબૂટ દરમિયાન ટકાવી રાખો, કારણ કે તેમના વિના પાછું આવતું સર્વર બરાબર તૂટેલા L2TP રૂપરેખાંકન જેવું દેખાય છે.

સર્વરના પોતાના LAN સુધી પહોંચવું બીજું કાર્ય છે: LAN રાઉટર પર પૂલ માટે પરત માર્ગ ઉમેરો, અથવા સર્વર પર proxy ARP ચાલુ કરો. જ્યારે LAN ની અંદરનું કંઈક ક્લાઇન્ટને સીધા સંબોધવાનું હોય ત્યારે તેમને NAT પાછળ છુપાવવું ફક્ત પછી માટે બીજું ડિબગિંગ સત્ર ગોઠવે છે.

નગ્ન સ્ટેક શું કરતું નથી, અને કેવી રીતે ચકાસવું

આ સ્ટેકનો કોઈ પણ ભાગ PPP ફ્રેમ્સને એન્ક્રિપ્ટ કરતો નથી, અને તેમાં કંઈ પણ દૂરના છેડાને તમે ખરેખર પસંદ કરેલા સર્વર તરીકે પ્રમાણિત કરતું નથી. MS-CHAPv2 ફક્ત જોનારા શ્રોતાથી ઓળખપત્રોની આપલે રક્ષે છે, તો પણ માર્ગમાં બેઠેલો હુમલાખોર સત્રમાં દખલ કરી શકે છે. Windows નો મૂળ ક્લાઇન્ટ L2TP ફક્ત IPsec સાથે જ આપે છે, તેથી Linux, રાઉટર ફર્મવેર અને તૃતીય પક્ષના ક્લાઇન્ટને તમારા સાથીઓ તરીકે ગણો. નગ્ન રૂપરેખાંકનને નિદાનનું પગથિયું ગણો, કદી અટકવાનું સ્થળ નહીં.

નિશ્ચિત ક્રમમાં ચકાસો: xl2tpd -D આગળના ભાગમાં ચલાવો, PPP તબક્કા માટે જર્નલ જુઓ, બંને છેડે ip addr માંથી ફાળવેલું સરનામું વાંચો, પછી સત્ર ઉપર આવ્યા પછી ડેટા વહે છે તેની પુષ્ટિ કરવા UDP 1701 કેપ્ચર કરો. જો ચારેય મેળ ખાય અને ટ્રાફિક હજી નિષ્ફળ જાય, તો દોષ રાઉટિંગ, NAT અથવા MTU માં છે, L2TP પોતે નહીં.