સાઇટ-થી-સાઇટ VPN નો જવાબ ટનલમાંથી પસાર થતો નથી
ટનલને ટાળતો જવાબ દૂરના છેડે લીધેલો રૂટિંગ નિર્ણય છે. હોસ્ટ ટેબલ, સિલેક્ટર અને rp_filter તપાસો, પછી રૂટ કે NAT પસંદ કરો.
મેં એક સવાર એ ટનલ પર ગાળી જે સ્વચ્છ રીતે ઉપર આવી અને ટ્રાફિકને બરાબર એક જ દિશામાં ખસેડ્યો: શાખા મુખ્ય કાર્યાલયના ફાઇલ સર્વર સુધી પહોંચી શકતી હતી, અને મુખ્ય કાર્યાલયથી શાખામાં ખૂલતું દરેક જોડાણ પહેલા SYN પર મૃત્યુ પામતું હતું. SA સક્રિય હતા, ટનલના કાઉન્ટર વધી રહ્યા હતા, અને હેન્ડશેક ક્યારેય સમસ્યા ન હતો. જવાબ એવી જગ્યાએ રૂટ થઈ રહ્યો હતો જ્યાં ટનલ પહોંચતી નથી, અને એ પસંદગી દૂરના છેડાની છે. સાઇટ-થી-સાઇટ VPN ફક્ત એ જ પેકેટ લઈ જાય છે જે હોસ્ટ ગેટવેને સોંપે છે, અને દરેક હોસ્ટ એ પસંદગી અલગથી, દરેક દિશામાં, પોતાના રૂટિંગ ટેબલમાંથી કરે છે.
બંને દિશાઓ અલગથી રૂટ થાય છે
IP વાતચીતની દિશાની કોઈ સ્મૃતિ રાખતું નથી. પેકેટ મોકલતું દરેક હોસ્ટ પોતાની સૌથી લાંબી પ્રીફિક્સ શોધ ચલાવે છે, એક આગળનું હોપ પસંદ કરે છે અને નિર્ણય ભૂલી જાય છે. વિનંતી અને જવાબ એ બે અસંબંધિત પેકેટ છે જે સંયોગવશાત એક જ જોડાણના છે, અને ટનલ એ એક હોપ છે જે બંનેમાંથી કોઈપણ વાપરી શકે કે ન વાપરે. IKE આદાનપ્રદાનમાં કંઈ પણ દૂરના સર્વરને તમારા સબનેટ સુધી કેવી રીતે પહોંચવું તે શીખવતું નથી; વાટાઘાટ ફક્ત એ વાત પર સહમત થાય છે કે કઈ પ્રીફિક્સ એન્ક્રિપ્ટ કરી શકાય.
એ સંમતિ બીજું દરવાજું છે. strongSwan પર ટ્રાફિક સિલેક્ટર leftsubnet અને rightsubnet છે, અને જે પેકેટનો સ્રોત કે ગંતવ્ય વાટાઘાટ કરેલ જોડીની બહાર પડે તે એન્ક્રિપ્ટ થતું નથી, રૂટિંગ ટેબલ ભલે ગમે તે કહે. જે પ્રીફિક્સ ટનલમાં રૂટ થાય છે પણ સિલેક્ટરમાં ખૂટે છે તે શાંત એકમાર્ગી નિષ્ફળતા છે: રૂટ સાચો લાગે છે, પેકેટ તો પણ ખુલ્લું નીકળે છે અથવા ફેંકાય છે, અને ફક્ત charon લોગ ફરિયાદ કરે છે.
દૂરનું હોસ્ટ તમારી ટનલ વિશે કંઈ જાણતું નથી
દૂરના LAN ની અંદર જવાબ તમારા ક્લાયન્ટને સંબોધિત સામાન્ય પેકેટ છે. ગંતવ્ય હોસ્ટને કોઈ IPsec હેડર દેખાતું નથી અને VPN ગેટવેને પ્રાધાન્ય આપવાનું કોઈ કારણ નથી; તે તમારો પ્રીફિક્સ શોધે છે, તેના ડિફોલ્ટ રૂટ કરતાં વધુ ચોક્કસ કંઈ મળતું નથી અને તેને અનુસરે છે. જો ડિફોલ્ટ કોઈ મુખ્ય ફાયરવોલ તરફ ઈશારો કરે, તો ફાયરવોલ પાસે ટનલમાં પાછા જવાનો રૂટ છે કે નથી. ન હોય તો તમને શાંત ડ્રોપ, ઇન્ટરનેટ તરફની ઇન્ટરફેસમાંથી નીકળીને મૃત્યુ પામતો જવાબ, અથવા ICMP unreachable મળે છે.
બીજી ઇન્ટરફેસ પૂરતી છે આને તોડવા માટે, રૂટ હોય તો પણ. બીજા VLAN પર મેનેજમેન્ટ લિંક ધરાવતું NAS, બેકઅપ uplink ધરાવતું સર્વર, એક સ્રોત-શ્રેણીને બીજા ટેબલમાં મોકલતો પોલિસી નિયમ: આમાંથી કોઈપણ જવાબને પકડી શકે છે. Linux પર, ip rule show અને ip route show table all એ નિયમો અને ટેબલ દર્શાવે છે જે ડિફોલ્ટ સૂચિ છુપાવે છે.
જવાબ મોકલતા મશીન પર નિર્ણય વાંચો
કંઈ બદલતા પહેલા કર્નલને પૂછો, અને તેને સ્રોત સરનામું આપો, કારણ કે સ્રોત-આધારિત નિયમો જવાબ બદલે છે.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"આઉટપુટ બહાર જતી ઇન્ટરફેસ અને આગળના હોપનું નામ આપે છે. જો ઇન્ટરફેસ એ ન હોય જે VPN ગેટવે તરફ જુએ છે, તો તમને ખામી મળી ગઈ છે, અને બાકીનું કામ એ નક્કી કરવાનું છે કે રૂટ ક્યાં હોવો જોઈએ. ગેટવેથી કરેલો ping અહીં ઓછું સાબિત કરે છે: તે એવા સરનામા સાથે જવાબ આપે છે જે દૂરનું હોસ્ટ મૂકી શકે, તમારા લેપટોપના સરનામા સાથે નહીં.
Windows પર સમકક્ષ Find-NetRoute -RemoteIPAddress 10.10.5.10 નિર્ણય માટે અને Get-NetRoute ટેબલ માટે છે. ડિફોલ્ટ કરતાં ઊંચી મેટ્રિક ધરાવતો New-NetRoute વડે ઉમેરાયેલો રૂટ શાંતિથી હારે છે, તેથી મેટ્રિક કોલમ વાંચો, એન્ટ્રી નહીં. પછી પેકેટથી ખાતરી કરો: દૂરની LAN ઇન્ટરફેસ પર tcpdump -ni any "host 10.10.5.10 and tcp port 445" વિનંતી દર્શાવે છે, અને ટનલની બાજુએ એ જ ફિલ્ટર દર્શાવે છે કે જવાબ પાછો આવ્યો કે નહીં. વિનંતી દેખાય પણ જવાબ ન હોય એટલે જવાબ અન્યત્ર રૂટ થયો અથવા ફેંકાયો; ખોટી ઇન્ટરફેસ પરનો જવાબ રૂટને સ્પર્શ કરતા પહેલા તમને દોષિત આપે છે.
જ્યારે સર્વરનું ગેટવે VPN એન્ડપોઇન્ટ ન હોય
ઘણી સાઇટ સર્વર અને કોન્સેન્ટ્રેટર વચ્ચે ફાયરવોલ મૂકે છે. એ ફાયરવોલ જવાબ ફોરવર્ડ કરે છે, તેથી તેને તમારા ક્લાયન્ટ પ્રીફિક્સ માટે VPN ગેટવે તરફ ઈશારો કરતો રૂટ અને બંને દિશામાં ફોરવર્ડિંગ પોલિસીની જરૂર છે. સ્ટેટફુલ ઉપકરણો વધુ ખરાબ કરે છે: વિનંતી ફાયરવોલને એ LAN હોસ્ટથી પાર કરી ગઈ જેને તેણે મંજૂરી આપી, હવે જવાબ બીજી દિશાથી આવે છે, અને કનેક્શન-ટ્રેકિંગ એન્ટ્રી હવે મેળ ખાતી નથી, તેથી પેકેટ નકારાયા વિના અમાન્ય તરીકે ફેંકાય છે. એટલે ટ્રાફિક અદૃશ્ય થતાં પોલિસી લોગ ખાલી દેખાય છે.
ગેટવેનું પોતાનું બીજું ફિલ્ટર છે. Linux નું રિવર્સ-પાથ ફિલ્ટરિંગ એ પેકેટ ફેંકે છે જેમનો સ્રોત એ ઇન્ટરફેસ દ્વારા પહોંચી શકાય તેમ નથી જેના પર તેઓ આવ્યા, અને તે કાયદેસર અસમમિત પરત માર્ગનો બરાબર આકાર છે. strongSwan ની ફોરવર્ડિંગ માર્ગદર્શિકા એટલા માટે net.ipv4.ip_forward અને ઢીલું net.ipv4.conf.all.rp_filter માંગે છે. કોઈપણ ગેટવે પર કડક મૂલ્ય 1 સાચો રૂટ શાંતિથી તોડે છે, અને ક્યાં જોવું એ ખબર હોય તો nstat -az ડ્રોપ દર્શાવે છે.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
રૂટ કરો કે અનુવાદ કરો, પછી બંને દિશામાં ચકાસો
બે સુધારા સમાન નથી. રૂટ ઉમેરવાથી ક્લાયન્ટનું સરનામું અકબંધ રહે છે, તેથી સ્રોત-આધારિત નિયમો, ઓડિટ લોગ અને કૉલર નોંધતી એપ્લિકેશનો કામ કરતી રહે છે; કિંમત એ છે કે નિર્ણય લેતા દરેક હોપને રૂટ જોઈએ, એટલે ભૂલ થવાની વધુ જગ્યાઓ. દૂરના ગેટવે પર માસ્કરેડ પરત માર્ગને એક હોપમાં સંકોચે છે, કારણ કે જવાબ હવે ગેટવેને જ સંબોધિત છે, અને કયા ક્લાયન્ટે શું કર્યું તે છુપાવે છે.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEતેને જાણી જોઈને પસંદ કરો: ક્લાયન્ટ ગેટવેના સરનામા તરીકે દેખાવા લાગે કે તરત, સ્રોત-આધારિત ACL તેમને અલગ પાડવાનું બંધ કરે છે, અને જવાબ ટનલમાં પાછો લખાય તે માટે conntrack એ મેપિંગ રાખવું પડે. જો સિલેક્ટર હજી ક્લાયન્ટ પ્રીફિક્સને બાકાત રાખે, તો NAT કંઈ બદલતું નથી, કારણ કે વિનંતી ક્યારેય ટનલમાં દાખલ થઈ ન હતી.
તેને સુધારેલું કહેતા પહેલા, ચાર વસ્તુ ક્રમમાં ખાતરી કરો: જવાબ મોકલતા હોસ્ટ પરનો રૂટ, તેને ફોરવર્ડ કરતા દરેક હોપ પરનો રૂટ, બંને પ્રીફિક્સ આવરી લેતા સિલેક્ટર, અને એવું કેપ્ચર જે દર્શાવે કે જવાબ તમે અપેક્ષા રાખો છો તે સ્રોત સાથે ટનલમાં પ્રવેશે છે. પછી બીજી સાઇટથી પરીક્ષણનું પુનરાવર્તન કરો. એક દિશા પસાર થવી એ અર્ધ-ખુલ્લી રચના છે, અને બીજી દિશા સામાન્ય રીતે તમે હમણાં સુધાર્યું તેના કરતાં અલગ કારણથી નિષ્ફળ જાય છે.