ઘરના રાઉટર પાછળ PPTP સર્વર: પહેલા 1723 અને GRE સુધારો

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

બે વાહક, અને તેમાંથી ફક્ત એકની પાસે પોર્ટ છે

PPTP બે વાહકમાં વિભાજિત થાય છે: TCP 1723 પર નિયંત્રણ જોડાણ, અને વધારેલા GREમાં લપેટાયેલા PPP ફ્રેમ, જે IP પ્રોટોકોલ 47 છે. GRE પાસે પોર્ટ નંબર નથી, તેથી પોર્ટ 1723 ફોરવર્ડ તરીકે લખાયેલો નિયમ તેને આવરી શકતો નથી, વેબ ઇન્ટરફેસ આ ક્ષેત્રને ગમે તે નામ આપે. ઉપભોક્તા રાઉટર સામાન્ય રીતે પ્રોટોકોલ નિયમની જગ્યાએ PPTP પાસથ્રુ નામનું ચેકબોક્સ આપે છે, અને તે ચેકબોક્સ બે કામ કરે છે: તે ફાયરવોલમાંથી પ્રોટોકોલ 47 પસાર થવા દે છે અને NATને GRE પ્રવાહ અનુસરવાનું શીખવે છે. Linux રાઉટર પર તે કામો અલગ મોડ્યુલો અને અલગ નિયમો છે, તેથી અડધું ગોઠવેલું પાસથ્રુ પણ કાર્યકારી નિયંત્રણ ચેનલ આપે છે. કંઈપણ બદલતા પહેલા કયો અડધો ભાગ હાજર છે તે જાણો.

સર્વરની પોતાની ફાયરવોલે પણ રાઉટરના સરનામાંથી પ્રોટોકોલ 47 મંજૂર કરવો જોઈએ. જે હોસ્ટ ફાયરવોલ ફક્ત 1723/tcp સ્વીકારે છે તે LANની અંદરથી ભૂલ 619 ફરી ઉત્પન્ન કરે છે, જેના કારણે તૂટેલું ફોરવર્ડિંગ અને તૂટેલો હોસ્ટ નિયમ સરખા દેખાય છે.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

જો મોડ્યુલો ન હોય, તો તેમને sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre વડે લોડ કરો અને લોડિંગ કાયમી બનાવો, કારણ કે સહાયકને ભૂલી જતું રીબૂટ કાર્યકારી ટનલને ફરી ભૂલ 619માં ફેરવે છે. ફોરવર્ડિંગ નિયમે ફક્ત સર્વરના સરનામા તરફ પ્રોટોકોલ 47 સ્વીકારવો જોઈએ, આખું LAN નહીં. RFC 2637 વ્યાખ્યા નિયંત્રણ અને માહિતી માર્ગને અલગ કરે છે, તેથી કોઈ પણ એક પોર્ટ ફોરવર્ડ સ્ક્રીન PPTPનું પૂર્ણ વર્ણન કરતી નથી.

પાસથ્રુ ચેકબોક્સ કે સ્પષ્ટ પ્રોટોકોલ નિયમ

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

1723 માટે ગંતવ્ય NAT નિયમ માં પણ માલિકીની સમસ્યા છે. જો જૂનો નિયમ હજી પણ 1723 એવા હોસ્ટ પર મોકલે જેણે સર્વર ચલાવવાનું બંધ કર્યું છે, તો પેકેટ બંધ પોર્ટ પર પડે છે અને રાઉટરની પોતાની PPTP સેવા જવાબ આપવાનું બંધ કરે છે, જે ફાયરવોલ નિષ્ફળતા જેવું વંચાય છે પણ વાસ્તવમાં જૂનું લક્ષ્ય છે. બીજો ઉમેરતા પહેલા નિયમ અને તેનું ગંતવ્ય વાંચો. જે રાઉટર પોતે PPTP સમાપ્ત કરે છે ત્યાં WAN નિયમ અંતર્નિર્મિત સેવા સાથે સ્પર્ધા કરે છે, તેથી 1723 અને પ્રોટોકોલ 47 માટે એક જ માલિક પસંદ કરો.

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

રાઉટરને દોષ આપતા પહેલા ટનલ માપો

PPTP ઉપયોગી પેલોડ ઘટાડે છે, અને આ ઘટાડો ગણિત છે, રહસ્ય નહીં. દરેક ટનલ પેકેટ બહારનું IP હેડર, વધારેલું GRE હેડર, PPP હેડર અને એન્ક્રિપ્શન સાથે MPPE હેડર વહન કરે છે. જ્યારે માર્ગ પરિણામી ફ્રેમ વહન કરી શકતો નથી, ત્યારે નાના પેકેટ પસાર થાય છે, લોગિન પૂર્ણ થાય છે, અને ફાઇલ સ્થાનાંતરણ કે TLS હેન્ડશેક પહેલી વાર પૂરા કદનું પેકેટ મોકલે ત્યારે સેશન અટકી જાય છે.

અનુમાન કરવાને બદલે સંખ્યા ગણો. વધારેલા GREનો 8 બાઇટ ખર્ચ થાય છે, PPPનો 4, MPPEનો 4, અને બહારના IP હેડરનો 20, તેથી ટનલ કોઈપણ પેલોડ પહેલા 36 બાઇટ ખાય છે. 1492 પર પૂરી થતી PPPoE WAN પર, બેસે તેવું સૌથી મોટું PPP MTU 1492 ઓછા 36 છે, એટલે કે 1456. PPP વિકલ્પોમાં mtu અને mru તે મૂલ્ય પર સેટ કરો અને વિભાજન ન કરતા પિંગ સાથે ફરી પરીક્ષણ કરો.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

પિંગ માર્ગ માપે છે, ટનલ નહીં: 1464 બાઇટ પેલોડ વત્તા 28 બાઇટ IP અને ICMP હેડર 1492 બાઇટની ફ્રેમ બરાબર ભરે છે. જો તે પિંગ નિષ્ફળ જાય, તો સંખ્યા ઘટાડતા જાઓ જ્યાં સુધી તે પસાર ન થાય, પછી પરિણામમાંથી 36 બાદ કરો. માર્ગની મર્યાદાથી ઉપર સેટ કરેલું ટનલ MTU કદનો ઉલ્લેખ કરતી કોઈ પણ લોગ લાઇન વિના થીજી જવાનું ઉત્પન્ન કરે છે.

એક જ રાઉટર પર PPTP, L2TP/IPsec કે OpenVPN

એક જ રાઉટર ત્રણ સામાન્ય ટનલમાંથી કોઈ પણ વહન કરી શકે છે, અને તફાવત એ છે કે તેણે શું વ્યક્ત કરવું પડે. PPTPને બે અલગ સ્તરોમાં બે નિયમોની જરૂર છે. IPsec ઉપર L2TP ને કી અદલાબદલી માટે UDP 500 અને 4500 જોઈએ, અને NAT-T તેને વહન ન કરે તો પેલોડ માટે પ્રોટોકોલ 50. OpenVPNને એક UDP પોર્ટ જોઈએ અને કોઈ સહાયક નહીં.

L2TP કૉલમ આપોઆપ GRE કરતાં વધુ મિત્રતાપૂર્ણ નથી. ESP એ IP પ્રોટોકોલ 50 છે અને તેની પણ પોર્ટ નથી, તેથી પ્રોટોકોલ 47 સાથે મુશ્કેલી અનુભવતું રાઉટર તે જ કારણે પ્રોટોકોલ 50 સાથે પણ મુશ્કેલી અનુભવી શકે છે. NAT-T ESPને UDP 4500ની અંદર લપેટવા માટે છે, અને જ્યારે બંને છેડા તેને સમર્થન આપે ત્યારે પ્રોટોકોલ 50નો નિયમ બિનજરૂરી બની જાય છે. તે છેડાઓની લાક્ષણિકતા છે, રાઉટરના PPTP ચેકબોક્સની નહીં. બંને માટે નિયમો લખતા પહેલા ક્લાયન્ટે ખરેખર કયું એન્કેપ્સ્યુલેશન વાટાઘાટ કર્યું તે નિશ્ચિત કરો.

OpenVPN એ રાઉટરની બાજુએ સૌથી ઓછા ચાલતા ભાગોવાળો વિકલ્પ છે. એક UDP પોર્ટ, એક ફોરવર્ડિંગ, કોઈ કનેક્શન-ટ્રેકિંગ સહાયક નહીં અને કૉલ ઓળખકર્તાનું કોઈ ફરી લખાણ નહીં. સોદો એ છે કે અંતર્નિર્મિત ડાયલરને બદલે ઇન્સ્ટોલ કરવો પડે તેવું ક્લાયન્ટ, અને ઘણી વાર એ જ એકમાત્ર કારણ છે કે PPTP વાતચીતમાં રહે છે.

શું સુધારવું અને શું બદલવું

ફોરવર્ડિંગ અને MTU સુધારવાથી તમને કામ કરતી ટનલ મળે છે, રાખવા જેવી નહીં. PPTPનું MSCHAPv2 પ્રમાણીકરણ વર્ષોથી હુમલાયોગ્ય છે, અને કાર્યકારી ટનલ એવા ઓળખપત્રો ખસેડે છે જે ઑફલાઇન પુનઃપ્રાપ્ત કરી શકાય. જો દૂરનું ઉપકરણ L2TP/IPsec કે OpenVPN ચલાવી શકે, તો સુધારાને તારીખ સાથેનું કામચલાઉ પગલું ગણો.

નિર્ણય એના પર આવે છે કે દૂરનો છેડો શું સમર્થન આપે છે અને ગોઠવણને કેટલો સમય ટકવું પડે. જે જૂનું ઉપકરણ ફક્ત PPTP બોલે છે તેને સુધારો મળે છે; ક્લાયન્ટ ઇન્સ્ટોલ કરી શકે તેવું બધું સ્થાનાંતરિત થાય છે.

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