Nebula சான்றிதழை மீண்டும் ஏற்றியதால் IP மாறவில்லை: காரணம் இதுவே
மீண்டும் ஏற்றுதல் overlay முகவரி அதேயாக இருக்கும்போது மட்டுமே ஹோஸ்ட் சான்றுகளை மீண்டும் படிக்கிறது. முகவரியை மாற்றுவது மறுதொடக்கம் மற்றும் வலையமைப்பு மாற்றம், மீண்டும் முயற்சி அல்ல.
வேறு overlay முகவரியுடன் புதிய ஹோஸ்ட் சான்றிதழை வழங்கி, அதைப் பழைய கோப்பின் மேல் நகலெடுத்து, மீண்டும் ஏற்றுதலை அனுப்பினாலும், ஹோஸ்ட் முந்தைய முகவரியிலேயே பதிலளிக்கிறது. இயல்பான எதிர்வினை, மீண்டும் ஏற்றுதல் தோல்வியடைந்தது அல்லது தவறான கோப்பு படிக்கப்பட்டது என்று கருதுவதாகும். பொதுவாக இரண்டும் நடக்கவில்லை: இயங்கும் செயல்முறை ஏற்கனவே இருந்த அடையாளத்தையே வேண்டுமென்றே தக்கவைத்துக்கொண்டது, ஏனெனில் மாற்றீடு மீண்டும் ஏற்றுதல் பயன்படுத்த முடியாத ஒன்றை மாற்றியது.
Nebula இன் PKI மீண்டும் ஏற்றுதல் ஆதரவு இந்த எல்லையுடனேயே ஆவணப்படுத்தப்பட்டுள்ளது, அதே ஆவணங்கள் மற்ற மாற்றங்களுக்கு மீண்டும் ஏற்றுதல் வேலை செய்வதைக் காட்டும்போது இதைத் தவறவிடுவது எளிது.
மீண்டும் ஏற்றுதல் உண்மையில் எதை மீண்டும் படிக்கிறது
ஹோஸ்ட் சான்றிதழ் SSH விசையைப் போல வெறும் சான்று அல்ல. அது overlay முகவரி, ஹோஸ்ட் பெயர், குழு உறுப்பினர் தகுதிகள் மற்றும் செல்லுபடியாகும் காலத்தைக் கொண்டுள்ளது, இவை அனைத்தும் CA இன் கையொப்பத்தால் ஒன்றிணைக்கப்படுகின்றன. டீமன் அந்தக் கையொப்பமிடப்பட்ட உள்ளடக்கத்தைப் பயன்படுத்தி தன்னை எவ்வாறு வழங்குவது, எந்த விதிகள் அதற்குப் பொருந்தும் என்பதைத் தீர்மானிக்கிறது.
மீண்டும் ஏற்றுதல் செயல்முறை தன் சுரங்கங்களை விடாமல் புதுப்பிக்கப்பட்ட சான்றுகளை எடுக்க அனுமதிக்கிறது, இது வழக்கமான சுழற்சிக்கு மதிப்புமிக்கது: அதே முகவரி, அதே பெயர், அதே குழுக்கள், பின்னர் காலாவதி. கட்டுப்பாடு என்னவென்றால் அடையாளம் அதேயாக இருக்க வேண்டும். overlay முகவரியை மாற்றினால் மீண்டும் ஏற்றுதல் பாதை அதைப் பயன்படுத்த முடியாது, ஏனெனில் முகவரி இயங்கும் நிகழ்வு ஏற்கனவே ஒப்புக்கொண்ட ஒன்றின் பகுதியாகும்.
எனவே நீங்கள் கண்ட நடத்தை ஆவணப்படுத்தப்பட்ட எல்லை தன் வேலையைச் செய்கிறது, அமைதியான தோல்வி அல்ல. வட்டில் உள்ள கோப்பு புதியது; நினைவகத்தில் உள்ள அடையாளம் பழையது; மறுதொடக்கம் இல்லாமல் அந்த வேறுபாட்டைச் சமரசம் செய்ய ஆதரவான வழி செயல்முறைக்கு இல்லை.
முகவரி, பெயர் மற்றும் குழுக்கள் ஒரே அடையாளம்
சான்றிதழைத் தனித்தனியாகத் திருத்தக்கூடிய புலங்களின் தொகுப்பாக அல்ல, ஒரே பதிவாகக் கருதுவது உதவுகிறது. முகவரியை நகர்த்துவது விருப்பத்தை மாற்றுவது போலல்ல, ஏனெனில் முகவரி மற்ற ஹோஸ்ட்களின் சக உள்ளமைவுகளிலும், சேவை இணைப்புகளிலும், அடையாளத்திற்கு எதிராக எழுதப்பட்ட கொள்கைகளிலும் தோன்றுகிறது.
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
குழுக்கள் தனிக் கோட்டிற்குத் தகுதியானவை, ஏனெனில் அவை அதே குழப்பத்தின் அமைதியான பதிப்பை ஏற்படுத்துகின்றன. முகவரியை வைத்துக்கொண்டு குழுக்களை மாற்றும் ஹோஸ்ட் மறுதொடக்கத்திற்குப் பின் வேறு சேவைகளை அடையலாம், பழைய முகவரிக்கு மட்டும் ping செய்யும் சோதனை முழுமையாக ஆரோக்கியமாகத் தோன்றும் அதே வேளையில் கீழே அணுகல் முடிவுகள் மாறியிருக்கும். அணுகல் மட்டுமல்ல, விதிக்கு உட்பட்ட ஒரு சேவையைச் சரிபார்க்கவும். சுரங்கத்தை உறுதிப்படுத்துவதற்கும் கொள்கையை உறுதிப்படுத்துவதற்கும் உள்ள வேறுபாடு அதுவே.
ஏற்றப்பட்ட சான்றிதழை மாற்றீட்டுடன் ஒப்பிடுங்கள்
டீமன் கோப்பைப் புறக்கணித்தது என்று கருதுவதற்கு முன் இரண்டையும் படியுங்கள். நீங்கள் ஏற்றப்போகும் சான்றிதழை அச்சிட்டு, மாற்றியதாக நீங்கள் கருதும் புலங்களை உறுதிப்படுத்தி, பின்னர் இயங்கும் உள்ளமைவு அந்தப் பாதையையே சுட்டுகிறதா, வேறெங்கும் உள்ள நகலையல்ல என்பதை உறுதிப்படுத்துங்கள்.
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)செயல்முறையின் அளபுருக்கள் மக்கள் எதிர்பார்ப்பதை விட முக்கியம். -config /etc/nebula/config.yml அனுப்பும் யூனிட் அந்தக் கோப்பின் pki.cert உள்ளீட்டைப் படிக்கிறது, தற்காலிக கோப்பகத்தில் நிறுவப்பட்ட சான்றிதழ் எதையும் பாதிக்காது. இயங்கும் கட்டளை வரியில் உள்ள பாதையைச் சரிபார்க்கவும், நீங்கள் பின்பற்றிய ஆவணத்தில் உள்ள பாதையை அல்ல. இரண்டும் வேறுபட்டால், சான்றிதழைத் தொடாமலேயே சிக்கலைக் கண்டுபிடித்துள்ளீர்கள்.
புதிய சான்றிதழுக்கு வேறு முகவரி இருந்து செயல்முறை பழையதை வைத்திருந்தால், இப்போது புதிரல்ல, விளக்கம் உள்ளது. ஏற்கத்தக்கதாக இருந்தால் அதை மறுதொடக்கம் செய்யுங்கள், முகவரி மாற்றத்தைத் தற்செயலானதாக அல்ல, திட்டமிட்ட வலையமைப்பு மாற்றமாகக் கருதுங்கள்.
முகவரி மாற்றம் வலையமைப்பு மாற்றம்
இயந்திரத்தை நகர்த்தத் திட்டமிடுவது போலவே இதைத் திட்டமிடுங்கள். மற்ற ஹோஸ்ட்கள் பழைய முகவரியைத் தங்கள் உள்ளமைவில் பொருத்தியிருக்கலாம், சேவைகள் அதனுடன் வெளிப்படையாக இணைந்திருக்கலாம், ஃபயர்வால் விதிகள் அதற்கு எதிராக எழுதப்பட்டிருக்கலாம். சான்றிதழை மாற்றுவது ஹோஸ்ட்டை நகர்த்துகிறது, ஹோஸ்ட்டை நகர்த்துவது வேறெங்கும் உள்ள ஊகங்களைச் செல்லாததாக்குகிறது.
இதைச் செய்யும்போது இரண்டாவது நிர்வாகப் பாதையைத் திறந்து வையுங்கள், ஏனெனில் நீங்கள் தடங்கல்படுத்துவது overlay இணைப்பாகவே இருக்கலாம். உடைக்கப்போகும் சுரங்கத்தின் மேலேயே இதைச் செய்வது ஐந்து நிமிட மாற்றத்தை இட வருகையாக மாற்றும் பாரம்பரிய வழி.
மறுதொடக்கம் ஏற்கத்தக்கதா என்பது ஹோஸ்ட் என்ன செய்கிறது என்பதைப் பொறுத்தது, இது தொழில்நுட்பமானது அல்ல, அட்டவணைப்படுத்தல் கேள்வி. கட்டாயமானது என்னவென்றால், மீண்டும் ஏற்றுதலை ஐந்தாவது முறையாக அனுப்புவதற்குப் பதிலாக மறுதொடக்கத்தின் தேவையை ஏற்றுக்கொள்வது.
பழைய சான்றைத் தனியாக ஓய்வு பெறச் செய்யுங்கள்
ஒரே இயந்திரத்தில் மாற்றீட்டை நிறுவுவது, ஒவ்வொரு சகனும் தனக்கு ஏற்கனவே தெரிந்த சான்றையே நம்புவதை விட்டுச் செல்கிறது. மாற்றத்திற்கான காரணம் பாதிப்பு என்றால், பழைய அடையாளம் நம்பிக்கை அல்லது தடுப்புப் பட்டியல் நடைமுறையின் மூலம் ஓய்வு பெறச் செய்யப்பட வேண்டும், அப்போதுதான் சகன்கள் அதை உண்மையில் நிராகரிப்பார்கள்.
இது தன் சொந்த சரிபார்ப்பைக் கொண்ட தனி படி: புதிய கோப்பு வேலையைச் செய்தது என்று கருதுவதற்குப் பதிலாக, பழைய அடையாளம் இனி வேலை செய்யவில்லை என்பதை வேறு ஹோஸ்ட்டிலிருந்து உறுதிப்படுத்துங்கள். Nebula PKI உள்ளமைவு ஆவணம் மீண்டும் ஏற்றக்கூடிய அமைப்புகளையும் இங்கு விவரிக்கப்பட்ட முகவரி வரம்பையும் உள்ளடக்கியது, உற்பத்தியில் எதையும் சுழற்றுவதற்கு முன் அதை முழுமையாகப் படிப்பது மதிப்புள்ளது.