pptpd પર GRE લખાણ નિષ્ફળતા પાસવર્ડ સમસ્યા નથી

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

બે સંદેશા, બે અલગ નિષ્ફળતા

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

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

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

પ્રોટોકોલ 47 એ પોર્ટ 47 નથી

PPTP કૉલ સેટ કરવા TCP 1723 અને પેલોડ વહન કરવા GRE વાપરે છે. GRE એ IP પ્રોટોકોલ 47 છે, પોર્ટ નંબર નહીં, તેથી પોર્ટ 47 ખોલતો ફાયરવૉલ નિયમ કંઈ ઉપયોગી મંજૂરી આપતો નથી.

માર્ગમાં રહેલા રાઉટરને PPTP passthrough સુવિધા અથવા સ્પષ્ટ GRE મંજૂરી જોઈએ. તેના વિના TCP હેન્ડશેક પૂર્ણ થાય છે અને ટનલ ક્યારેય પેકેટ વહન કરતી નથી, જે ઉપરની વાંચન નિષ્ફળતા જ ઉત્પન્ન કરે છે. ફાયરવૉલમાં પોર્ટ 47 નિયમો આ પ્રોટોકોલમાં સૌથી વધુ બગડેલી બપોર છે.

કઈ બાજુ ટ્રાફિક ફેંકે છે તે અનુમાન કરવાને બદલે સર્વર પર બંને દિશા એકસાથે જુઓ: tcpdump -ni any port 1723 or proto gre.

જો 1723 કૉલ સેટઅપ દર્શાવે અને GRE શાંત રહે, તો અવરોધ હોસ્ટની ઉપર છે. જો GRE આવે અને ડિમન હજી પણ નિષ્ફળ જાય, તો સમસ્યા સ્થાનિક છે અને વિકલ્પો જોવાનું આગળનું સ્થળ છે.

હોસ્ટ ખરેખર ફોરવર્ડ કરે ત્યાં GRE ને મંજૂરી આપો

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

સર્વરને જ સંબોધિત પેકેટ માટે input નિયમ ઉમેરો, કારણ કે forward શૃંખલા તેમને જોતી નથી. પછી જોડાણ પ્રયાસ પહેલાં અને પછી નિયમના કાઉન્ટર જુઓ, જે કહે છે કે પેકેટ આવે છે કે નહીં.

દરેક રીબૂટ પછી ફરી ચલાવવાને બદલે વિતરણની ફાયરવૉલ સેવા દ્વારા નિયમને ટકાઉ રાખો. nftables હોસ્ટ પર input અને forward બંને શૃંખલામાં ip protocol gre મેળવો.

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

તમારી પાસે ખરેખર જે ક્લાયન્ટ છે તેની સાથે વિકલ્પો મેળવો

બીજા અહેવાલનો સુધારો /etc/ppp/pptpd-options માં છે, જ્યાં રેસીપી PAP, CHAP અને MSCHAP ના નકાર કરે છે, અનુરૂપ require લીટીઓ ટિપ્પણી કરે છે અને સ્ટેટફુલ MPPE રાખે છે. એ રેસીપી એક ક્લાયન્ટ મિશ્રણ માટે લખાઈ હતી, અને આંધળી નકલ સામાન્ય કેસ તોડે છે. નકારની લીટીઓને સૂચન તરીકે નહીં, પણ લેખક પાસે કયા ક્લાયન્ટ હતા તેના નિવેદન તરીકે વાંચો.

Windows ક્લાયન્ટને સામાન્ય રીતે MS-CHAPv2 સાથે MPPE-128 જોઈએ. એ જરૂરિયાતો રાખો અને ફક્ત એ વિકલ્પો દૂર કરો જે ક્લાયન્ટ ખરેખર વાટાઘાટ કરી શકતો નથી.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

ક્લાયન્ટનો ભૂલ નંબર વાંચો

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

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

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