VPN પર SSH દર મિનિટે કપાય છે? કારણ keepalive નથી

SSH જોડાય છે, લગભગ એક મિનિટ કામ કરે છે, પછી દર વખતે લગભગ એ જ અંતરાલે થીજી જાય છે. સામાન્ય સમજૂતી નિષ્ક્રિય ટાઈમઆઉટ છે, તેથી લોકો MTU ઘટાડે છે અને ક્લાયન્ટ keepalive સેટ કરે છે. મેં જે WireGuard લિંક પર કામ કર્યું તે પહેલેથી જ આ બધું પસાર કરી ચૂકી હતી: નાનું ટનલ MTU, client-alive સેટિંગ્સ, રૂપરેખાંકિત ટનલ keepalive. વિક્ષેપો અપરિવર્તિત ચાલુ રહ્યા. કારણ અસમમિત LAN રૂટ નીકળ્યું, અને આ પેટર્ન ઓળખવા જેવી છે કારણ કે તે ટાઈમર-આધારિત દરેક ઉપાયને હરાવે છે.

keepalive સાબિત કરે છે કે તમારો હોસ્ટ હજી મોકલવા તૈયાર છે. તે સ્થિતિ રાખતા ઉપકરણને એવો જવાબ જોવા દે શકતું નથી જે ક્યારેય તેમાંથી પસાર થતો નથી.

દંતકથા: keepalive નીરવ વિચ્છેદ સુધારે છે

SSH keepalive એક જ કામ માટે છે: જે નીરવતા ગણે છે તે નિષ્ક્રિય સત્રને દૂર ન કરે. તે તેઓ સારી રીતે કરે છે. તેઓ સ્થિતિ રાખતા ઉપકરણની સમસ્યા હલ કરતા નથી જેણે એક દિશામાં પ્રથમ પેકેટ જોયું અને પછી ક્યારેય જવાબ જોયો નહીં, કારણ કે ક્લાયન્ટ મોકલે છે તેમાંથી કંઈ પણ જવાબ કઈ ઇન્ટરફેસ વાપરે છે તે બદલતું નથી.

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

સંકેત નિયમિતતા છે, સાથે એવું સત્ર જે તે અંતરાલની અંદર વાપરી શકાય તેવું રહે છે. નિષ્ક્રિય ટાઈમઆઉટ ત્યારે ફટકે છે જ્યારે કંઈ થતું નથી; આ ત્યારે ફટકે છે જ્યારે તમે ટાઈપ કરો છો.

વધારાનું ગેટવે ખરેખર શું કરે છે

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

નીચેની સરનામાં તે ગોઠવણ દર્શાવે છે:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

આમાંથી કંઈ પણ ક્લાયન્ટ રૂપરેખાંકનમાં દેખાતું નથી, તેથી તેની શોધ સામાન્ય રીતે ખોટી ફાઇલમાં શરૂ થાય છે.

એક જાણી જોઈને પસંદ કરેલો માર્ગ પસંદ કરો

ઉપરની ગોઠવણ માટે, દૂરના સબનેટને સીધા VPN ગેટવે પર રૂટ કરવાથી અડધું જોડાણ દૂર થાય છે:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

બંને છેડેથી પરીક્ષણ કરો

લેપટોપનો ગંતવ્ય તરફનો રૂટ અને ગંતવ્યનો લેપટોપ તરફ પાછો રૂટ વાંચો; તે બે અલગ નિર્ણયો છે અને સંભવતઃ તેમાંથી એક જ ખોટો છે. ગેટવે પોતેથી સફળ થતું ping સમસ્યાને સંપૂર્ણ છુપાવી શકે છે, કારણ કે તે એ મશીન પર ઉદ્ભવે છે જેનો માર્ગ પહેલેથી જ સાચો છે. તમને વાસ્તવિક સત્રના બંને છેડા જેવી બંને દિશાઓની જરૂર છે.

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

અસમમિતિ ક્યારે બરાબર છે

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

ટકાઉ જવાબ બે માર્ગોના નામ આપે છે, જે ઉપકરણને બંને જોવા જરૂરી છે તેનું નામ આપે છે, અને જે રૂટ તેને શક્ય બનાવે છે તેનું નામ આપે છે. જો તમે ઉપકરણનું નામ ન આપી શકો, તો તમે હજી કારણ શોધ્યું નથી.