Docker માં PPTP પ્રમાણીકરણ કરે છે પણ કોઈ ટ્રાફિક વહન કરતું નથી

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

પાંચ તપાસ, જે ક્રમ સૌથી વધુ સમય બચાવે છે તેમાં.

તપાસ 1: નિયંત્રણ ચેનલને પેલોડથી અલગ કરો

PPTP TCP 1723 પર પ્રમાણીકરણ કરે છે અને પછી PPP પેલોડને GRE, IP પ્રોટોકોલ 47 ની અંદર વહન કરે છે. GRE ન તો TCP છે ન UDP, તેથી નિયંત્રણ પોર્ટ ફોરવર્ડ કરતો દરેક નિયમ તેના વિશે કંઈ કહેતો નથી. 1723 પાસ કરતું NAT અથવા ફાયરવોલ પ્રોટોકોલ 47 ને ફરિયાદ વિના પડતું મૂકી શકે છે, અને સેશન અડધું બનેલું રહે છે એ રીતે જે સફળતા જેવું લાગે છે.

જો લોગિન કામ કરે અને કોઈ પેકેટ પાછું ન આવે, તો પહેલા GRE ધારો અને પછી તેને સાબિત કરો.

તપાસ 2: હોસ્ટ કર્નલમાં હેલ્પરની ખાતરી કરો

કનેક્શન ટ્રેકિંગ હેલ્પર વિના TCP નિયંત્રણ જોડાણને GRE પ્રવાહ સાથે જોડી શકતું નથી. મોડ્યુલ nf_conntrack_pptp છે, તે હોસ્ટ કર્નલમાં રહે છે, અને કન્ટેનર ઇમેજની અંદર તેને લોડ કરવાથી કંઈ થતું નથી કારણ કે મોડ્યુલ સમગ્ર હોસ્ટ પર લાગુ પડે છે. Docker હોસ્ટ પર lsmod | grep nf_conntrack_pptp એ તપાસ છે. જો તે ન હોય, તો modprobe nf_conntrack_pptp ચાલુ કર્નલ માટે તેને લોડ કરે છે અને આગલા બૂટ વિશે કંઈ કહેતું નથી, તેથી તેને હોસ્ટ રૂપરેખાંકનમાં પણ ઉમેરો.

રીબૂટ પર અદૃશ્ય થતું મોડ્યુલ આગલા મહિને એ જ ટિકિટ બની જાય છે.

તપાસ 3: જે કર્નલ નીતિ તેને બંધ કરે છે તે વાંચો

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

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

તપાસ 4: કન્ટેનરનો માર્ગ અલગથી જુઓ

લોડ થયેલો હેલ્પર રૂટ બનાવતો નથી. કન્ટેનરને PPTP સર્વર સુધીનો માર્ગ જોઈએ છે, અને હોસ્ટ ફોરવર્ડિંગે બંને દિશામાં GRE ને મંજૂરી આપવી પડે છે: iptables -L FORWARD -v -n બતાવે છે કે પ્રોટોકોલ 47 સ્વીકારાય છે કે નહીં અને કાઉન્ટર ખસે છે કે નહીં. Docker ના masquerade નિયમો TCP અને UDP નું ભાષાંતર કરે છે, પ્રોટોકોલ 47 નું નહીં, તેથી બ્રિજ કન્ટેનરને સ્પષ્ટ forward સ્વીકૃતિ અને કેટલાક હોસ્ટ પર પોતાનો ભાષાંતર નિયમ જોઈ શકે છે. એ પણ ખાતરી કરો કે કન્ટેનરમાં તેની ઇમેજ જે PPP ઉપકરણ સપોર્ટ ધરાવે છે તે છે.

નિયમનું લખાણ નહીં, કાઉન્ટર વાંચો. જે નિયમ અસ્તિત્વમાં છે પણ કંઈ સાથે મેળ ખાતો નથી તે શણગાર છે.

તપાસ 5: GRE ટ્રેક થાય છે તે સાબિત કરો, પછી PPTP વિશે નિર્ણય લો

ક્લાયન્ટ ચાલુ હોય ત્યારે ટ્રેકિંગ ટેબલ વાંચો. સ્થાપિત PPTP નિયંત્રણ એન્ટ્રી અને સંબંધિત GRE એન્ટ્રી એટલે હેલ્પર પ્રવાહોને જોડે છે અને બાકીની ખામી બીજે ક્યાંક છે. GRE એન્ટ્રી વિનાની નિયંત્રણ એન્ટ્રી એટલે પેલોડ પડતું મૂકાય છે અથવા ટ્રેક થતું નથી, જે તમને તપાસ 2 અને 3 પર પાછા લાવે છે.

PPTP પોતે જૂનું છે અને MS-CHAPv2 નબળું છે. જો સર્વર L2TP/IPsec, IKEv2 અથવા WireGuard પણ આપે છે, તો તેમાંથી એક પર જવાથી આ આખો વર્ગની સમસ્યાઓ દૂર થાય છે.

જ્યાં PPTP રહેવું જ પડે, ત્યાં કન્ટેનરની અંદર નહીં પણ હોસ્ટ પર ક્લાયન્ટ ચલાવવો NAT અને ફિલ્ટરિંગનું એક સ્તર દૂર કરે છે, જે ઘણી વાર સસ્તું નિર્ણય છે.