PPTP કનેક્ટ થાય અને પછી Linux NAT પાછળ અટકી જાય: GRE હેલ્પર

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

ફોરવર્ડ ક્યારેય સમસ્યા નહોતું

પોર્ટ-ફોરવર્ડ નિયમ TCP અથવા UDP ટ્રાફિકનું વર્ણન કરે છે. તે એવા પેલોડનું વર્ણન કરી શકતો નથી જે સેશનની વચ્ચે બીજા IP પ્રોટોકોલ પર જાય છે, અને PPTP બરાબર એ જ કરે છે.

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

નિયંત્રણ માટે TCP, ડેટા માટે GRE

કૉલ TCP 1723 પર વાટાઘાટ થાય છે. તે ઊભો થયા પછી પેલોડ GRE માં જાય છે, IP પ્રોટોકોલ 47, જે કોઈ પોર્ટ નંબર લેતો જ નથી. પોર્ટ પર આધારિત નિયમ પાસે મેળવવા જેવું કંઈ નથી.

GRE જે લે છે તે તેના હેડરમાં કૉલ ઓળખકર્તા છે, અને NAT અનુવાદકે તે ક્ષેત્રને બંને દિશામાં સુસંગત રીતે ફરીથી લખવું પડે, નહીં તો સેશનના બે ભાગ એકબીજા સાથે સંમત થવાનું બંધ કરે છે. એક દિશા ફરીથી લખાયેલી અને બીજી નહીં તેવું સેશન પ્રમાણીકરણ કરે છે અને પછી દરેક ડેટા પેકેટ ફેંકી દે છે. લક્ષણનો આકાર બરાબર એ જ છે: સફળતા, પછી મૌન.

PPTP વિનાના નગ્ન GRE ને આવી ફરીલખાઈની જરૂર નથી, તેથી સાદો GRE ટનલ એવા રાઉટરમાંથી કામ કરી શકે છે જે તે જ રસ્તા પર PPTP ક્લાયન્ટ માટે નિષ્ફળ જાય.

ચાર મોડ્યુલ અને એક sysctl જેણે તેમને બંધ કર્યા

બે મોડ્યુલ ફ્રેમિંગ સંભાળે છે, nf_conntrack_proto_gre અને nf_nat_proto_gre. બીજા બે કૉલ ઓળખકર્તા સંભાળે છે, nf_conntrack_pptp અને nf_nat_pptp. છેલ્લાને લોડ કરવાથી બાકીના આધારો દ્વારા આવે છે, તેથી મોડ્યુલ યાદીમાં ચારેય દેખાવા જોઈએ.

જૂની સૂચનાઓ 2.6 યુગના ip_ ઉપસર્ગનો ઉપયોગ કરે છે. તે આદેશો કંઈ લોડ ન કરતાં ચાલતા હોય તેમ લાગી શકે છે, તેથી એક્ઝિટ સ્થિતિને બદલે લોડ થયેલી યાદી તપાસો.

તેમને લોડ કરેલા રાખવા હવે પૂરતું નથી. Linux 4.7 થી net.netfilter.nf_conntrack_helper sysctl ડિફોલ્ટ 0 છે, જે નવા ફ્લો માટે સ્વચાલિત હેલ્પર ફાળવણી બંધ કરે છે. રાઉટરમાં દરેક મોડ્યુલ હોઈ શકે અને તેમ છતાં કંઈ અનુવાદ ન થાય. ફરી મોડ્યુલ યાદી જોતા પહેલાં અસરકારક મૂલ્ય તપાસો.

કાં તો સ્વચાલિત ફાળવણી ફરી વૈશ્વિક રીતે ચાલુ કરો, અથવા હેલ્પરને જરૂરી ફ્લો સાથે જોડો અને બાકીનું બધું શાંતિથી રહેવા દો:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

બીજો વિકલ્પ પસંદ કરવા જેવો છે. તે આખા રાઉટર પર સ્વચાલિત ફાળવણી ફરી ચાલુ કરવાને બદલે વર્તનને PPTP ટ્રાફિક સુધી મર્યાદિત કરે છે.

પોર્ટ વગરનો પ્રોટોકોલ ખોલવો

1723 ને મંજૂરી આપતો ફાયરવોલ નિયમ પ્રોટોકોલ 47 વિશે કંઈ કહેતો નથી. firewalld પર ક્લાયન્ટ તરફના ઝોનમાં પ્રોટોકોલને મંજૂરી આપો. સાદા iptables પર ઇનપુટ ચેઇનમાં gre પ્રોટોકોલ સ્વીકારો.

પછી બંને બાજુ કેપ્ચર કરો. ક્લાયન્ટ છોડતા પેકેટના કોઈ જવાબ ન આવે તો અર્થ એ છે કે પરતનો રસ્તો ફિલ્ટર થયેલો છે, અને તે નકારાયેલા ઓળખપત્ર કરતાં અલગ ખામી છે.

કનેક્ટ થયા પછી કદની મર્યાદા

GRE હેડર ઉમેરે છે, અને તેની અંદરનું PPP વધુ ઉમેરે છે, તેથી કામ કરતી લિંક 1500 થી ઘણું નીચે MTU જણાવે છે. નાના પ્રતિભાવો લોડ થાય છે અને મોટા અટકી જાય છે, જે પ્રથમ સમસ્યા હલ થાય તે ક્ષણે દેખાતી બીજી, અસંબંધિત સમસ્યા જેવું લાગે છે.

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

રસ્તો સુધારવાથી વપરાશકર્તા કામ પર આવે છે, અને તે PPTP ને સારો વિકલ્પ બનાવતું નથી. MS-CHAPv2 અને RC4 ઘણા સમય પહેલાં નિવૃત્ત થયા છે, તેથી મોડ્યુલ લોડ કરવાને અસ્થાયી સુધારો ગણો અને જાળવાયેલા પ્રોટોકોલ તરફ જવાનું આયોજન કરો.