OpenVPN નું સંપૂર્ણ ટનલ તમારું SSH સેશન કાપી નાખે છે: જવાબનો માર્ગ સુધારો

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

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

જવાબ ખોટા દરવાજેથી કેમ નીકળે છે

આવતા પેકેટ હજી પણ ભૌતિક ઇન્ટરફેસ પર આવે છે, કારણ કે VPN ક્લાયંટ બદલી શકતું નથી કે ઇન્ટરનેટ તમારા સર્વરના જાહેર સરનામા સુધી કેવી રીતે પહોંચે છે. જવાબો અલગ નિર્ણય છે: દરેક પેકેટ માટે કર્નલ લક્ષ્ય શોધે છે, અને --redirect-gateway પછી ડિફોલ્ટ એન્ટ્રી ટનલ કહે છે. પ્રદાતાનું એગ્ઝિટ એવું લક્ષ્ય જુએ છે જે તે સેવા આપતું નથી અને પેકેટ ફેંકી દે છે.

OpenVPN નું પોતાનું રક્ષણ બરાબર એક લક્ષ્યને આવરે છે. 2.6 માર્ગદર્શિકા --redirect-gateway ને ક્રમ તરીકે વર્ણવે છે: તે ટનલ પહેલાં વપરાયેલા ગેટવે દ્વારા VPN પીઅર માટે હોસ્ટ રૂટ ઉમેરે છે, જેથી એન્ક્રિપ્ટેડ ટ્રાફિક પોતાના અંદર પાછો ન ફરી શકે, અને પછી ડિફોલ્ટ રૂટ બદલે છે. તે હોસ્ટ રૂટ ફક્ત પીઅર માટે છે. તમારો SSH ક્લાયંટ ફક્ત બીજું ઇન્ટરનેટ સરનામું છે અને કોઈ અપવાદ મળતો નથી.

એક પ્રીફિક્સ ભૂલ વહેલા બાકાત કરવા જેવી છે. લંબાઈ વગરનું ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 એકમાત્ર સરનામા 0.0.0.0 સાથે મેળ ખાય છે, ઇન્ટરનેટ સાથે નહીં; તે 0.0.0.0/0 હોવું જોઈએ. અને જો ડિફોલ્ટ લેવાથી ટનલનું પોતાનું પરિવહન તૂટે, તો ભૌતિક ઇન્ટરફેસ દ્વારા એન્ડપોઇન્ટને હોસ્ટ રૂટ તરીકે ઉમેરો, પ્રદાતાના વાસ્તવિક સરનામા સાથે.

તાત્કાલિક ઉકેલ માટે તમારું SSH ક્લાયંટ સરનામું પિન કરો

સૌથી ઝડપી સુધારો એ છે કે ટનલ પહેલાં સર્વરે વાપરેલા ગેટવે દ્વારા તમારા ક્લાયંટ સરનામા માટે હોસ્ટ રૂટ. તમારી બાજુથી, સર્વર જે સરનામું જોશે તે શોધો, પછી જૂનો ગેટવે જાણવા સર્વરનું ટેબલ વાંચો:

curl -s https://ifconfig.co
ip route

સર્વર પર, ક્લાયંટ શરૂ થાય તે પહેલાં અપવાદ ઉમેરો. અહીંના સરનામાં પ્લેસહોલ્ડર છે; આકાર મહત્વનો છે:

sudo ip route add 80.128.240.55 via 192.168.178.1

આ જાહેર કરાયેલા કિસ્સામાં વપરાયેલો સુધારો છે, અને તે તરત જ કામ કરે છે. તે બે અનુમાનિત રીતે નાજુક પણ છે: રીબૂટ પર રૂટ અદૃશ્ય થાય છે, અને જે ક્ષણે તમારો ISP તમને બીજું સરનામું આપે છે તે ક્ષણે તે ખોટો બને છે. તેને કટોકટીના પગલા તરીકે ગણો અને જાણી જોઈને ટકાઉ બનાવો, નેટવર્ક યુનિટ અથવા ડિસ્પેચર હૂક દ્વારા, અથવા સ્વીકારો કે તે હંગામી છે અને પુનઃપ્રાપ્તિનો માર્ગ લખી રાખો.

ક્લાયંટને ડિફોલ્ટ લેતું અટકાવો

વધુ સ્વચ્છ વિકલ્પ એ છે કે ટનલને ડિફોલ્ટ રૂટ બદલવા દેવું જ નહીં. route-nopull, --client અથવા --pull સાથે વપરાય છે ત્યારે, રૂટ સિવાયના ધકેલાયેલા વિકલ્પો, block-outside-dns અને DNS સર્વર જેવા DHCP-શૈલીના વિકલ્પો સ્વીકારે છે, તેથી તમે ફક્ત જરૂરી પ્રીફિક્સ ઉમેરો છો. વધુ સાંકડું સાધન પુલ ફિલ્ટર છે, જે એક સમસ્યારૂપ સૂચના કાઢી નાખે છે અને બાકીનું રાખે છે:

route-nopull
pull-filter ignore "redirect-gateway"

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

પરતનો માર્ગ સ્રોત પ્રમાણે કે કનેક્શન પ્રમાણે વિભાજિત કરો

જ્યારે આવતું સરનામું સ્થિર હોય, ત્યારે સ્રોત નિયમ ટનલના પોતાના રૂટને સ્પર્શ કર્યા વિના જવાબોને સ્થાનિક રાખે છે. ભૌતિક ઇન્ટરફેસ સરનામાને LAN પ્રીફિક્સ અને ભૌતિક ડિફોલ્ટ સાથેનું પોતાનું ટેબલ આપો, પછી તેમાંથી આવતા ટ્રાફિક માટે તે ટેબલ પસંદ કરો:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

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

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

પરીક્ષણ દરમિયાન કનેક્શન ચિહ્ન, ફાયરવોલ ચિહ્ન અને ટેબલ નંબર અલગ રાખો. બે ભૂમિકાઓ માટે એક નંબર ફરીથી વાપરવાથી એવો નિયમ બને છે જે સાચો દેખાય છે અને ખોટા પેકેટ સાથે મેળ ખાય છે. ટેબલની ડિફોલ્ટ એન્ટ્રીને સામાન્ય ઇથરનેટ લિંક પર LAN ગેટવે સાથે via ની પણ જરૂર છે; નક્કોર dev eth0 ફક્ત ત્યારે જ કામ કરે છે જ્યારે ઇન્ટરફેસ પોઇન્ટ-ટુ-પોઇન્ટ હોય અથવા આગલું હોપ બીજી રીતે ઉકેલાય છે. જાહેર કરાયેલ Jessie હોસ્ટ કોઈ એવી લિંક પર હતું જ્યાં નક્કોર સ્વરૂપ કામ કરતું હતું, જે નકલ કરવા જેવો કોઈ ડિસ્ટ્રિબ્યુશન નિયમ નથી.

બહાર તાળું માર્યા વિના ચકાસો

ડિસ્કનેક્ટ કરીને પરીક્ષણ કરશો નહીં. પહેલું સેશન ખુલ્લું રાખો, ટનલ ઉપર લાવો, અને કર્નલને પૂછો કે તમારું પોતાનું સરનામું કયો માર્ગ લેશે:

ip route get 80.128.240.55

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

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