VPN ટનલ ક્યારેય કનેક્ટ થતી નથી: પેકેટ ખરેખર ક્યાં અટકે છે

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

ટ્રાફિક ક્યાં અટકે છે તે સાબિત કરો

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

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

પ્રોટોકોલ 47 વગર PPTP મરે છે

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

પાસથ્રુ ઇનબાઉન્ડ ફોરવર્ડની વિરુદ્ધ દિશામાં ચાલે છે, અને ફર્મવેર ઘણી વાર બંને માટે એક જ લેબલ વાપરે છે, જે બધાને મૂંઝવવા પૂરતું છે. Linux ક્લાયન્ટ પર સ્થાનિક ફાયરવોલ રાઉટર સામેલ થવાના ઘણા સમય પહેલા GRE કાઢી શકે છે, તેથી પ્રોટોકોલ 47 ને પોતાનો નિયમ જોઈએ અને conntrack સહાયક લોડ થવું જોઈએ. Ubuntu નું ufw આ નિયમો before ફાઇલમાં રાખે છે, કારણ કે સામાન્ય allow નિયમો પ્રોટોકોલ નંબર વ્યક્ત કરી શકતા નથી. પછી મશીન રીબૂટ કરવાને બદલે ફાયરવોલ ફરી લોડ કરો.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

બે NAT પાછળ L2TP અને IPsec

L2TP IPsec ની અંદર કી વિનિમય માટે UDP 500, NAT મળે ત્યારે UDP 4500, અને પ્રોટોકોલ 50 તરીકે ESP ની જરૂર પડે છે. તેમાંથી દરેક સ્વતંત્ર રીતે ફિલ્ટર થાય છે, તેથી એકને મંજૂરી આપતો નિયમ બાકીના બે વિશે કંઈ સાબિત કરતો નથી. શ્રેણીમાં બે રાઉટર દરેક પેકેટનું બે વાર ભાષાંતર કરે છે, અને છેડા હવે એ વિશે સહમત નથી કે શું વાટાઘાટ થયું.

બહારના મોડેમને બ્રિજ કરો, અથવા અંદરના રાઉટર પર NAT બંધ કરો, જેથી જાહેર સરનામું ટનલ સમાપ્ત કરતા ઉપકરણ સુધી પહોંચે. જ્યાં બંનેમાંથી એક પણ શક્ય ન હોય, ત્યાં ટનલ ડબલ NAT સીમાની અંદરથી શરૂ કરવી પડશે, ત્યાં સમાપ્ત નહીં.

કેરિયર નેટવર્ક અને સરનામા વહેંચણી

WAN સરનામું 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 અથવા 100.64.0.0/10 ની અંદર હોવાનો અર્થ છે કે રાઉટર પાસે જાહેર સરનામું નથી અને ઇન્ટરનેટથી કોઈ ઇનબાઉન્ડ ફોરવર્ડ તેને પહોંચી શકતું નથી. કેરિયર-ગ્રેડ NAT વધુમાં એવા પ્રોટોકોલ ફિલ્ટર કરે છે જેની તે અપેક્ષા રાખતું નથી, અને મોબાઇલ લિંક પર GRE વારંવાર ભોગ બને છે. રાઉટર પરના WAN સરનામાની સરખામણી કરો, તેની પાછળના ક્લાયન્ટ માટે લુકઅપ સાઇટ જે સરનામું જણાવે છે તેની નહીં.

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

પોર્ટ બંધ કરતા પહેલા શ્રોતાઓની યાદી વાંચો

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther ના ડિફોલ્ટ સારો ઉદાહરણ છે: TCP 443, 992 અને 5555, સાથે L2TP/IPsec અને DNS-ટનલ ફીચર તેમના પોતાના સોકેટ ઉમેરે છે. તે ફીચર બંધ કરવાથી શ્રોતાઓ છુપાવવાને બદલે દૂર થાય છે, અને બહારના હોસ્ટથી પ્રોબ તમને જણાવે છે કે કેરિયર પોર્ટને જવા દે છે કે નહીં. સ્થાનિક રીતે જવાબ આપતો શ્રોતા હજી પણ ઉપરના પ્રવાહમાં બંધ હોઈ શકે છે, તેથી રાઉટરના પોતાના WAN સરનામાની સરખામણી બહારની સેવા જે જણાવે છે તેની સાથે કરો.