OpenVPN ટનલ દ્વારા IPv6: ઘરના રાઉટર માટે પગલે પગલે માર્ગદર્શિકા

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

ક્લાયન્ટ જ્યાં બેઠો છે ત્યાંથી શરૂ કરો

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

પછી ક્લાયન્ટ બહારની દુનિયા વિશે શું માને છે તે તપાસો. ટનલ પરનો ડિફોલ્ટ રૂટ બધો IPv6 ટ્રાફિક માંગે છે, જ્યારે 2000::/3 માટેનો રૂટ ફક્ત ગ્લોબલ યુનિકાસ્ટ માંગે છે. બંને સાચા હોઈ શકે છે, અને તેઓ લીક વિશે જુદા જુદા પ્રશ્નોના જવાબ આપે છે.

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

સર્વર ખરેખર જે પૂલ રૂટ કરી શકે તે તપાસો

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

પૂલ અને ધક્કો સાથે જ રહે છે. server-ipv6 2001:db8:80:10::/64 સરનામાં ફાળવે છે, અને push "route-ipv6 2000::/3" ક્લાયન્ટને કહે છે કે ટનલમાં શું મોકલવું. 2000::/3 ધકેલવાથી ગ્લોબલ યુનિકાસ્ટ આવરી લેવાય છે અને link-local તથા multicast શ્રેણીઓ ટનલની બહાર રહે છે.

પસંદ કરેલું પ્રીફિક્સ ડિપ્લોયમેન્ટ રેકોર્ડમાં લખો. આગલી વારે ISP હેન્ડઓફ બદલનારને જાણવું જોઈએ કે ટનલ કયું /64 પહેલેથી રોકે છે.

બીજા કુટુંબ માટે ફોરવર્ડિંગ ચાલુ કરો

IPv4 ફોરવર્ડિંગનો અર્થ IPv6 ફોરવર્ડિંગ નથી. net.ipv6.conf.all.forwarding=1 સેટ કરો અને IPv4 FORWARD નીતિ પહેલેથી જે મંજૂર કરે છે તે બધું પ્રતિબિંબિત કરો. જે રાઉટરની FORWARD શૃંખલા ડિફોલ્ટ રૂપે કાઢી નાખે છે, ત્યાં નિયમોનો સમૂહ ખૂટે તો બરાબર મૃત ટનલ જેવું લાગે છે.

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

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

ઉપરની બાજુ રૂટ ન કરે ત્યારે પડોશી શોધનો જવાબ આપો

ઉપરનું સાધનકાર્ય ક્યારેક સોંપાયેલા /64 ને પોતાની કડીનું ગણે છે અને VPN બોક્સ તરફ કોઈ પણ ઉપ-પ્રીફિક્સ રૂટ કરવાની ના પાડે છે. એવું થાય ત્યારે કોઈકે દરેક ક્લાયન્ટ સરનામા માટે અલગ અલગ પડોશી વિનંતીઓનો જવાબ આપવો પડે.

OpenVPN ફાળવેલું સરનામું client-connect હૂકને આપે છે, તેથી એન્ટ્રીઓ હાથે રાખેલી યાદીને બદલે ખરા પૂલને અનુસરી શકે છે. હૂક ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 ઉમેરે છે, અને અનુરૂપ client-disconnect હૂક તેને દૂર કરે છે. દૂર ન કરવાથી પ્રોક્સી કોષ્ટક જૂનું થાય છે અને પછીનો ક્લાયન્ટ એવા સરનામાની એન્ટ્રી વારસામાં મેળવી શકે છે જે તેણે ક્યારેય મેળવ્યું નથી. ip -6 neigh show proxy વડે સ્થિતિ ખાતરી કરો.

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

બહાર તરફનો રસ્તો અનુસરો, એક હોપ વખતે

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

ટનલના MTU પર નજર રાખો, કારણ કે રસ્તાના IPv6 રાઉટર તમારા વતી ટુકડા કરશે નહીં. વધારે મોટું MTU સ્વચ્છ નિષ્ફળતાને બદલે packet-too-big ભૂલ અને અટકેલું TLS તરીકે દેખાય છે. તેને સ્પષ્ટ રીતે સેટ કરો અને મર્યાદાની નજીકના પેલોડ સાથે કસોટી કરો.