अमेज़ॅन EC2 के लिए dynDNS या गतिशील सार्वजनिक आईपी के साथ होस्टिंग पर आईपी ऑटो-नवीनीकरण को स्वचालित कैसे करें

हाल ही में, कार्य एक निश्चित सेवा के लिए Amazon EC2 पर Ubuntu 12.04 वर्चुअल सर्वर को तैनात करना था और इसे मौजूदा डोमेन ज़ोन में एक डोमेन नाम असाइन करना था, लेकिन जैसा कि आप जानते हैं, अमेज़न मशीन को रिबूट या बंद करने के बाद अपने सार्वजनिक और स्थानीय पते बदलता है, इसलिए इसे बैश (* निक्स) के लिए उपयोग करने का निर्णय लिया गया था बल्लेबाजी (विंडोज के लिए) होस्टिंग के लिए गतिशील पते को अपडेट करने के लिए।


इस तरह की बैश स्क्रिप्ट पहले से ही Marius Ducea Jun 1st, 2009 में मौजूद है । यह थोड़ा अप्रासंगिक था जिसके संदर्भ में अमेज़ॅन एपीआई की आज्ञा है, लेकिन अधिकांश भाग के लिए यह लगभग अपरिवर्तित रहा।
फिर भी, मैं दोहराऊंगा कि सिंक्रनाइज़ेशन के लिए कमांड प्राप्त करने के लिए एक कामकाजी BIND को कैसे कॉन्फ़िगर किया जाए, हालाँकि इस विधि का वर्णन करने वाले हब पर पहले से ही कई लेख हैं:
habrahabr.ru/post/101380
habrahabr.ru/post/45921
और कई अन्य।

मैंने अभी कुछ कमांड्स तय की हैं, इसे सिस्टम के साथ स्टार्टअप में अटका दिया है और विंडोज के लिए एक समान बैट-स्क्रिप्ट बनाई है, CURL और BIND की कुछ फाइलों का उपयोग किया है।

मुझे लंबे समय तक यह महसूस करना पड़ा कि ज़ोन को अपडेट करना संभव क्यों नहीं है (मास्टर और गुलाम एक और होस्टिंग पर थे, उबंटू 10.04 पर बंड के साथ काम करते हुए), मुझे इस पर लॉगिंग को सक्षम करना पड़ा:

/Etc/bind/onym.conf फ़ाइल में, मैं लॉग बनाने के लिए नियम निर्धारित करता हूं, जिसे फ़ोल्डर में / var / log / name /

logging { channel bind_log { file "/var/log/named/named.log"; print-time yes; print-category yes; print-severity yes; }; channel update_debug { file "/var/log/named/update-debug.log"; severity debug 3; print-time yes; print-category yes; print-severity yes; }; channel security_info { file "/var/log/named/security-info.log"; severity info; print-time yes; print-category yes; print-severity yes; }; category default { bind_log;}; category xfer-in { bind_log;}; category xfer-out { bind_log;}; category update { update_debug;}; category security { security_info;}; }; 

के बाद

 /etc/init.d/bind9 restart 

लॉग दिखाई दिए और आप एक स्क्रिप्ट के साथ ज़ोन को अपडेट करने का प्रयास कर सकते हैं जिसे थोड़ा संशोधित किया गया था, लेकिन पहले आपको चाबियाँ बनानी थीं, मैंने 512 बिट्स का उपयोग किया:

 dnssec-keygen -a HMAC-MD5 -b 512 -r /dev/urandom -n USER example.com 

2 फाइलें मिलीं:

 Kexample.com.+157+10000.key Kexample.com.+157+10000.private 

स्क्रिप्ट में, आपको प्राप्त निजी कुंजी के लिए पथ निर्दिष्ट करना होगा:

 #!/bin/bash #     DNS_KEY="/etc/bind/key/Kexample.com.+157+10000.private" #  DOMAIN=example.com #   HOSTNAME=site1 #  2 ,      (      DNS) #USER_DATA=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/local-hostname` #HOSTNAME=`echo $USER_DATA` #     hostname $HOSTNAME.$DOMAIN echo   : $HOSTNAME.$DOMAIN PUBIP=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/public-ipv4` echo  : $PUBIP cat<<EOF | /usr/bin/nsupdate -k $DNS_KEY -v server ns1.$DOMAIN zone $DOMAIN update delete $HOSTNAME.$DOMAIN A update add $HOSTNAME.$DOMAIN 60 A $PUBIP send EOF LOCIP=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/local-ipv4` echo  : $LOCIP cat<<EOF | /usr/bin/nsupdate -k $DNS_KEY -v server ns1.$DOMAIN zone $DOMAIN update delete local.$HOSTNAME.$DOMAIN A update add local.$HOSTNAME.$DOMAIN 60 A $LOCIP send EOF 

, और DNS सर्वर में, लोड किए गए ज़ोन की फ़ाइल में सार्वजनिक कुंजी की सामग्री निर्दिष्ट करें (मेरे लिए यह नाम है ।conf.local):

 key example.com. { algorithm HMAC-MD5; secret "ynl7o+JFPekH4iUaptw7z12xLhkUBJTmqbmTYa1xe+Gpt26HVaff+qQW hlmWcvAUeYdg19B+M4YeFrfhAvlcLQ=="; }; zone "example.com" { type master; file "/etc/bind/master/example.com"; allow-update { key example.com.; }; allow-query { any; }; }; 

सार्वजनिक कुंजी सामग्री:

 example.com. IN KEY 0 3 157 ynl7o+JFPekH4iUaptw7z12xLhkUBJTmqbmTYa1xe+Gpt26HVaff+qQW hlmWcvAUeYdg19B+M4YeFrfhAvlcLQ== 

हम मास्टर / दास-रिकॉर्ड DNS सर्वर के साथ होस्टिंग सर्वर को रिबूट करते हैं और अमेज़ॅन होस्टिंग पर प्राप्त स्क्रिप्ट के साथ ज़ोन को अपडेट करने का प्रयास करते समय लॉग को देखते हैं।

गंदगी मिली थी:
named.log

 26-Jan-2013 22:53:27.780 update-security: info: client 192.168.254.1#58180: signer "example.com" approved 26-Jan-2013 22:53:27.782 general: error: /etc/bind/master/example.com.jnl: create: permission denied 26-Jan-2013 22:53:27.881 update-security: info: client 192.168.254.1#52062: signer "example.com" approved 26-Jan-2013 22:53:27.883 general: error: /etc/bind/master/example.com.jnl: create: permission denied 

अद्यतन-debug.log

 26-Jan-2013 22:53:27.780 update: info: client 192.168.254.1#58180: updating zone 'example.com/IN': deleting rrset at 'flussonic.example.com' A 26-Jan-2013 22:53:27.781 update: info: client 192.168.254.1#58180: updating zone 'example.com/IN': adding an RR at 'flussonic.example.com' A 26-Jan-2013 22:53:27.781 update: debug 3: client 192.168.254.1#58180: updating zone 'example.com/IN': checking for NSEC3PARAM changes 26-Jan-2013 22:53:27.782 update: info: client 192.168.254.1#58180: updating zone 'example.com/IN': error: journal open failed: unexpected error 26-Jan-2013 22:53:27.882 update: info: client 192.168.254.1#52062: updating zone 'example.com/IN': deleting rrset at 'local.flussonic.example.com' A 26-Jan-2013 22:53:27.882 update: info: client 192.168.254.1#52062: updating zone 'example.com/IN': adding an RR at 'local.flussonic.example.com' A 26-Jan-2013 22:53:27.882 update: debug 3: client 192.168.254.1#52062: updating zone 'example.com/IN': checking for NSEC3PARAM changes 26-Jan-2013 22:53:27.883 update: info: client 192.168.254.1#52062: updating zone 'example.com/IN': error: journal open failed: unexpected error 

यह लॉग में लिखा गया था कि कोई लिखित अनुमति नहीं थी, हालांकि फ़ाइलों और फ़ोल्डरों ने उपयोगकर्ता और बाइंड समूह के लिए अनुमति लिख दी थी।
इंटरनेट पर खोजों ने कहा कि आपको /etc/apparmor.d/usr.sbin/mail में लाइन को सही करने की आवश्यकता है
ग

 /etc/bind/** r, 

पर

 /etc/bind/** rw, 

, लेकिन इसका मतलब इस निर्देशिका में स्थित क्षेत्रों की सुरक्षा को कम करना है, लेकिन हमेशा की तरह मैं यादृच्छिकता पर भरोसा करता हूं।
इसके बाद, आपको अनुमतियाँ पुनः लोड करने की आवश्यकता है और स्वयं को बांधें

 /etc/init.d/apparmor restart /etc/init.d/bind9 restart 

DNS होस्टिंग पर सेवा के अगले पुनरारंभ के बाद, त्रुटि गायब हो गई और ज़ोन सफलतापूर्वक अपडेट हो गया, लेकिन इसमें टिप्पणी की गई सभी डेटा खो गया, क्योंकि रिकॉर्ड में "चीजों को क्रम में रखें" को हटा दें और अतिरिक्त को हटा दें, इसलिए आपको सभी जोनों की एक प्रति बनानी चाहिए ।

साथ ही, इस स्क्रिप्ट को ऑटोरन बनाया जाना चाहिए, क्योंकि वर्चुअल मशीन को चालू करने के बाद, ssh के माध्यम से भयानक नाम ec2-55-240-2-74.compute-1.amazonaws.com (लगातार बदलते हुए) में जाना और ज़ोन को अपडेट करने के लिए इसे अपने हाथों से चलाना असुविधाजनक है।
ऐसा करने के लिए, मैंने इसे निष्पादन योग्य बनाया और इसे /etc/init.d/ पर कॉपी किया

 chmod +x ec2-hostname.sh cp ec2-hostname.sh /etc/init.d/ update-rc.d ec2-hostname.sh defaults 

विंडोज के लिए, सब कुछ बहुत सरल हो गया:

 @echo off Setlocal enabledelayedexpansion rem      set DNS_KEY="Kexample.com.+157+10000.private" rem   set DOMAIN=example.com rem   set HOSTNAME=site1 echo   : %HOSTNAME%.%DOMAIN% for /F "Delims=" %%P In ('curl -s http://169.254.169.254/latest/meta-data/public-ipv4') Do Set PUBIP=%%~P echo  : %PUBIP% ( @echo server ns1.%DOMAIN% @echo zone %DOMAIN% @echo update delete %HOSTNAME%.%DOMAIN% A @echo update add %HOSTNAME%.%DOMAIN% 60 A %PUBIP% @echo send ) | nsupdate -k %DNS_KEY% -v for /F "Delims=" %%L In ('curl -s http://169.254.169.254/latest/meta-data/local-ipv4') Do Set LOCIP=%%~L echo  : %LOCIP% ( @echo server ns1.%DOMAIN% @echo zone %DOMAIN% @echo update delete local.%HOSTNAME%.%DOMAIN% A @echo update add local.%HOSTNAME%.%DOMAIN% 60 A %LOCIP% @echo send ) | nsupdate -k %DNS_KEY% -v :eof 

और इसे सिस्टम स्टार्टअप पर लॉन्च के साथ एक शेड्यूलर में डाल दिया।
मैंने यहाँ cURL का नवीनतम संस्करण लिया: www.paehl.com/open_source
BIND: www.isc.org/software/bind
BIND से केवल फाइलों की जरूरत है:

 libisc.dll liblwres.dll libisccfg.dll libbind9.dll libeay32.dll libdns.dll libxml2.dll nsupdate.exe 

आप उन्हें स्क्रिप्ट के बगल में रख सकते हैं या उन्हें% WINDIR% \ system32 में छोड़ सकते हैं

इस सब से निष्कर्ष:
हालाँकि मैंने यह कार्य पूरा कर लिया है, क्योंकि DNS सर्वर की सुरक्षा और भी छोटी हो गई है, क्योंकि एक अन्य भेद्यता जोड़ी गई और सही ढंग से कॉन्फ़िगर किए गए ज़ोन को खोने का जोखिम।
यहां जो लिखा गया है उसे दोहराने से पहले, आपको स्पष्ट रूप से समझना चाहिए कि आपको क्या प्राप्त करने की आवश्यकता है, सभी महत्वपूर्ण और परिवर्तनशील वस्तुओं की एक प्रति बनाएं, आपको यह सुनिश्चित करने की आवश्यकता है कि किसी भी विफलता के मामले में आप मशीन तक पहुंच सकते हैं और स्थिति को ठीक कर सकते हैं।
मैं परिणामों के लिए जिम्मेदार नहीं हूं, क्योंकि वह खुद भी इसकी शुद्धता के बारे में सुनिश्चित नहीं है।

पुनश्च
मैं इस तरह के भ्रमित पाठ, और संभावित त्रुटियों के लिए माफी माँगता हूँ।