VPN સર્વરને નવા જાહેર IP પર ખસેડવું: પહેલા શું તપાસવું
જગ્યા પર બદલી અને સમાંતર કટઓવર અલગ અલગ જગ્યાએ તૂટે છે. કન્ફિગ, NAT અને પ્રમાણપત્રો તપાસો, પછી જુઓ કે દરેક ક્લાયન્ટ નામ કેવી રીતે ઉકેલે છે.
સરનામું ફરીથી ફાળવવામાં એક મિનિટ લાગે છે. પછીનું અઠવાડિયું એ જગ્યા છે જ્યાં ખસેડવું તૂટે છે, અને ભાગ્યે જ ત્યાં જ્યાં પ્રદાતાનું કન્સોલ સૂચવે છે. નવું જાહેર IP ચાર જગ્યાએ સંદર્ભિત થાય છે: જે સોકેટ પર ડેમન સાંભળે છે, ક્લાયન્ટ જે ભરોસાના એન્કરને ચકાસે છે, જૂના સરનામાને નામ આપતો દરેક નિયમ, અને તે DNS રેકોર્ડ જે તેમને જોડે છે. બે ખસેડવાની ક્રિયાઓ કંટ્રોલ પેનલથી એકસરખી દેખાય છે પણ વર્તનમાં સંપૂર્ણ ભિન્ન છે: તમે ચલાવો છો તે મશીન પર સરનામું ફરીથી ફાળવવું, અથવા બીજું એન્ડપોઈન્ટ ઊભું કરીને ક્લાયન્ટને ત્યાં ખસેડવા. નીચેની તપાસો સસ્તી નિષ્ફળતાઓને પહેલા મૂકે છે, અને દરેક વિભાગ જણાવે છે કે તે કઈ ખસેડવાની ક્રિયા પર લાગુ પડે છે.
જગ્યા પર બદલી અને સમાંતર કટઓવર અલગ કામો છે
જગ્યા પર બદલી હોસ્ટ, કી, રૂટિંગ ટેબલ અને વપરાશકર્તા યાદી રાખે છે; ફક્ત સરનામું બદલાય છે. ફ્લોટિંગ IPની ફરી ફાળવણી આ જ કરે છે, અને ઘણા પ્રદાતાઓ પર અતિથિને કંઈ જ ખબર પડતી નથી, કારણ કે અનુવાદ ઇન્સ્ટન્સની સામે થાય છે. રીબિલ્ડ અથવા પ્રદાતા દ્વારા ફરી ફાળવણી વધુ કઠોર છે: અતિથિ ફેરફાર જુએ છે, અને જૂનું મૂલ્ય કેશ કરેલું દરેક વસ્તુ તે જ ક્ષણે તે શીખે છે.
સમાંતર એન્ડપોઈન્ટ એ બીજું હોસ્ટ છે જે એ જ કામ કરે છે. તેને બનાવો, એક પ્રોફાઇલ સાથે પરીક્ષણ કરો, અને નવું વાસ્તવિક માર્ગ પર પોતાને સાબિત કરે ત્યાં સુધી જૂનાને જવાબ આપવા દો. કિંમત સ્થિતિ છે. વહેંચાયેલ પીઅર એન્ટ્રી, રદ કરવા અને લોગિંગ વિના તમારી પાસે બે નેટવર્ક છે જે કોઈક રીતે એક નામ વહેંચે છે.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
જૂનું સરનામું જ્યાં લખાયેલું છે તે દરેક જગ્યા શોધો
ટેક્સ્ટ સ્કેનથી શરૂ કરો, કારણ કે કન્ફિગરેશન ફાઇલો સરળ અડધો ભાગ છે. ડેમન કન્ફિગ, ફાયરવોલ ટુકડા, મોનિટરિંગ લક્ષ્યો અને ડિસ્ક પરનું કોઈપણ જનરેટ થયેલ ક્લાયન્ટ બંડલ શોધો. જો તમે IPv6 સરનામું પ્રકાશિત કરો તો તેનો પણ સમાવેશ કરો; ફક્ત A રેકોર્ડને અનુસરતું ખસેડવું ડ્યુઅલ-સ્ટેક ક્લાયન્ટને જૂના માર્ગ પર છોડી દે છે.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsપછી કર્નલ સ્કેન કરો, કારણ કે ચાલતી સિસ્ટમ સરનામું એવી જગ્યાએ રાખે છે જેનો કોઈ ફાઇલ ઉલ્લેખ કરતું નથી. સ્થિર સ્રોત NAT નિયમ, ipset એન્ટ્રી, બાઇન્ડ સરનામું અને conntrack એન્ટ્રી તેમને દૂર કરનાર કન્ફિગ ફેરફાર કરતાં વધુ ટકે છે, અને કેટલીક રીબૂટ પણ ટકી જાય છે કારણ કે તે સાચવેલા નિયમસેટમાંથી પાછી આવે છે. એક સ્તર ઉપર, પ્રદાતાના સુરક્ષા જૂથો, લોડ બેલેન્સર લક્ષ્યો અને મોનિટરિંગ ચેક તમારી ફાઇલસિસ્ટમ પર જ નથી.
કંઈપણ બદલતા પહેલા ઇન્વેન્ટરી લખો; તે રોલબેક સ્ક્રિપ્ટ તરીકે પણ કામ કરે છે.
હોસ્ટનામ ક્લાયન્ટ સુધરે છે; લિટરલ-IP ક્લાયન્ટ શાંત થઈ જાય છે
જો ક્લાયન્ટ હોસ્ટનામ દ્વારા સર્વર સુધી પહોંચે છે, તો કટઓવર મુખ્યત્વે DNS સમસ્યા છે, અને ગઈકાલે તમે સેટ કરેલ TTL નક્કી કરે છે કે તે કેટલું ખરાબ થશે. રિઝોલ્વર કેશ કરે છે, સ્ટબ રિઝોલ્વર ફરી કેશ કરે છે, અને ઘણા ક્લાયન્ટ નામ ફક્ત નવા કનેક્શન પર શોધે છે, તેથી સ્થાપિત ટનલ તેનું શરૂઆતનું સરનામું રાખે છે.
જો એન્ડપોઈન્ટ લિટરલ સરનામું છે, તો કંઈ ફરી ઉકેલાતું નથી અને કંઈ ફરિયાદ લોગ કરતું નથી. WireGuard ઉકેલાયેલ સોકેટ સરનામું સંગ્રહે છે: Endpoint = vpn.example.net:51820 જે ક્ષણે wg-quick up ચાલે છે ત્યારે IP બને છે અને તમે તેને બદલો ત્યાં સુધી તે IP જ રહે છે. OpenVPN વધુ સહિષ્ણુ છે: તે કનેક્શન સમયે remote હોસ્ટનામ ઉકેલે છે અને resolv-retry infinite સાથે ફરી જોડાણ વખતે ફરી DNS પ્રયાસ કરે છે. લિટરલ IP આપવામાં આવે ત્યારે બંને એવા મશીનને ડાયલ કરતા રહે છે જે હવે અસ્તિત્વમાં નથી.
લોકોને ભ્રમિત કરે છે તે અરીસાની છબી. નવા સરનામા તરફ પહેલેથી નિર્દેશિત ક્લાયન્ટ, જ્યારે જૂનું શ્રોતા હજી જવાબ આપે છે, ત્યારે તમારા પોતાના ડેસ્કથી કરેલી દરેક કસોટી પાસ કરે છે. હું છેતરાયો છું તેમાં: નવું એન્ડપોઈન્ટ ફોન પર એક જ પ્રયાસમાં ઉપર આવ્યું, અને જૂની પ્રોફાઇલવાળો ક્લાયન્ટ ફક્ત ત્યારે પ્રગટ થયો જ્યારે જૂનું શ્રોતા ઘણું પછી બંધ કરવામાં આવ્યું.
ભરોસો સરનામા સાથે ખસતો નથી
WireGuard ઓળખને પહોંચથી અલગ પાડે છે, જે સરનામું ખસેડવાનું લગભગ મફત બનાવે છે. પીઅર જાહેર કી દ્વારા ઓળખાય છે, અને એન્ડપોઈન્ટ ફક્ત તે જ જ્યાં પેકેટ અત્યારે જાય છે; હોસ્ટ તાજેતરના પ્રમાણિત પેકેટના સ્રોત સરનામાથી પીઅરનું એન્ડપોઈન્ટ અપડેટ કરે છે. નિષ્ક્રિય પીઅરને હજી પણ નવી જગ્યા સાથે વાત કરવાનું કારણ જોઈએ, અને તે સરનામું ફક્ત ત્યારે શીખે છે જ્યારે તેનું સત્ર જૂનું થાય અને હેન્ડશેકના ફરી પ્રયાસો ક્યાંક દૃશ્યમાન જગ્યાએ નિષ્ફળ જાય. WireGuardની ઝડપી શરૂઆત એન્ડપોઈન્ટ ક્ષેત્રને આવરે છે.
TLS આધારિત સર્વર વિરુદ્ધ કિસ્સો છે. પ્રમાણપત્ર નામ સાથે બંધાયેલું છે, અને સરનામું ડાયલ કરતો ક્લાયન્ટ જે ડાયલ કર્યું તેને વિષયના વૈકલ્પિક નામો સાથે સરખાવે છે. ફક્ત DNS SAN ધરાવતા પ્રમાણપત્ર સાથે IP દ્વારા જોડાઓ અને ચકાસણી નિષ્ફળ જાય છે: ક્લાયન્ટે વાપરેલું નામ પ્રમાણપત્રમાં નથી. IP SAN સાથે ફરી જારી કરવાથી તે એક કનેક્શન સુધરે છે અને આગલું ખસેડવું વધુ ખરાબ બને છે. પ્રોફાઇલમાં હોસ્ટનામ રાખવું અને verify-x509-name તેની જગ્યાએ રાખવું ચકાસણીને કડક રાખે છે જ્યારે નીચેનું સરનામું બદલાય છે.
પછી તપાસો કે ડેમન શેનાથી બંધાયેલો છે; જૂના સરનામા સાથે પિન થયેલું સોકેટ શાંતિથી નિષ્ફળ જાય છે. local 203.0.113.10 સાથે શરૂ કરેલ OpenVPN સર્વર તે સરનામું ગયા પછી ઉપર આવવાનો ઇનકાર કરે છે, જ્યારે 0.0.0.0 પરનું શ્રોતા ફેરફારને મફતમાં અનુસરે છે. NAT એ જ રીતે વિભાજિત થાય છે: MASQUERADE હવે મશીન પાસે જે સરનામું છે તેને અનુસરે છે, અને સ્થિર SNAT --to-source 203.0.113.10 હવે તમારી પાસે ન હોય તેવા સરનામા પર ફરી લખવાનું ચાલુ રાખે છે, તેથી પરત ટ્રાફિક અદૃશ્ય થાય છે. જો નવું સરનામું અલગ અપસ્ટ્રીમ ગેટવે સાથે આવે, તો rp_filter તપાસો: રિવર્સ-પાથ ફિલ્ટરિંગ એવા ઇન્ટરફેસ પર આવતા પરત ટ્રાફિકને કાઢી નાખે છે જેની કર્નલને અપેક્ષા ન હતી.
કટઓવરનો ક્રમ અને તે કામ કર્યું તેના પુરાવા
એક દિવસ પહેલા TTL ઘટાડો, નવું શ્રોતા ઊભું કરો, અને ફક્ત તમારી પાસે હોય તેવી પ્રોફાઇલથી તેને સાબિત કરો. એ જ નેટવર્કની અંદરથી કરેલી કસોટી લગભગ કંઈ સાબિત કરતી નથી, તેથી સેલ્યુલર પરનો ફોન વાપરો અને એન્ડપોઈન્ટ પર પિંગ કરવાને બદલે ટનલ જે વહન કરવાની છે તે વસ્તુનું પરીક્ષણ કરો.
આખી વિન્ડો દરમિયાન બંને સરનામાં જુઓ. નવા હોસ્ટ પર wg show all latest-handshakes, અથવા OpenVPN સ્ટેટસ ફાઇલ, તમને કહે છે કે કેટલા પીઅર ખરેખર ખસ્યા છે. જ્યારે નવા એન્ડપોઈન્ટ પાસે અપેક્ષિત પીઅર હોય અને જૂનામાં ફક્ત પાછળ રહેલા હોય, ત્યારે જૂનું શ્રોતા નિવૃત્ત કરો, જૂનો NAT નિયમ દૂર કરો અને પ્રદાતાના ફાયરવોલમાંથી સરનામું કાઢી નાખો. જૂનું શ્રોતા દૂર કરવું એ જ પગલું છે જે છોડી દેવાય છે, અને તે તે ખાલી જગ્યા બંધ કરે છે જ્યાં જૂની પ્રોફાઇલ હજી જૂના નેટવર્ક સુધી પહોંચે છે.
શરૂ કરતા પહેલા રોલબેક ટ્રિગર લખાયેલું નક્કી કરો: જો સંમત વિન્ડો પછી નવા એન્ડપોઈન્ટને એક પણ વાસ્તવિક ક્લાયન્ટ તરફથી હેન્ડશેક ન મળે, તો જૂનું સરનામું પુનઃસ્થાપિત કરો અને પ્રોફાઇલ વિતરણ બંધ કરો. પછી સ્કેન ફરી ચલાવો અને ખાતરી કરો કે કોઈ શ્રોતા હજી નિવૃત્ત સરનામા સાથે બંધાયેલું નથી. બે વસ્તુઓ આગલી ખસેડવાની ક્રિયામાં જાય છે: ક્લાયન્ટ પ્રોફાઇલમાં હોસ્ટનામ જેથી આગળનો ફેરફાર DNS સંપાદન હોય, અને સર્વરની રિકવરી નોંધોની બાજુમાં સંગ્રહિત ઇન્વેન્ટરી.