სტატიკური IP მისამართები: როდის გჭირდება და როდის არა

უმეტეს სერვერს გამოყოფილი მისამართი არ სჭირდება. მას სჭირდება სტაბილური სახელი, ანუ DNS ჩანაწერი, და ეს ორი მუდმივად ერევა ერთმანეთში. თუ შენი მოთამაშეები და მომხმარებლები hostname-ით უკავშირდებიან, მისამართი ქვემოთ შეიძლება შეიცვალოს ისე, რომ ვერავინ შეამჩნიოს - სწორედ ამისთვის დადე მის წინ სახელი. არსებობს რამდენიმე ნამდვილი შემთხვევა, როცა საკუთარი მისამართი არჩევითი აღარ არის, და ისინი საკმარისად კონკრეტულია, რომ ჩამოვთვალოთ. დანარჩენი ყველაფერი ინვოისზე ერთი ხაზია.

ეს პოსტი განასხვავებს სამ რამეს, რასაც ადამიანები "static IP"-ს უწოდებენ, გადის შემთხვევებს, რომლებიც მართლა მოითხოვს მას, და მოიცავს ორ პრობლემას, რომელიც ხალხს მის საძებნელად უბიძგებს: სახლის კავშირი, რომლის მისამართიც იცვლება, და სახლის კავშირი, რომელსაც საჯარო მისამართი საერთოდ არ აქვს.

სტატიკური, გამოყოფილი და shared სამი განსხვავებული რამეა#

ეს სიტყვები ერთმანეთის ნაცვლად გამოიყენება და განსხვავებულ თვისებებს აღწერს. მათი განცალკევება თავისთავად დაბნეულობის დაახლოებით ნახევარს აქრობს.

ჰოსტინგზე მყოფ სერვერს ჩვეულებრივ აქვს მისამართი, რომელიც სტატიკურია და საჯარო, მაგრამ shared. ის შემდეგ თვესაც იგივე იქნება, ინტერნეტს მისი მიღწევა შეუძლია და სხვა მომხმარებლების რამდენიმე სერვერი იმავე მისამართზე სხვა port-ებზე პასუხობს. სახლის ბროდბენდ კავშირი ჩვეულებრივ დინამიკურია, საჯაროა და შენთვის გამოყოფილია, სანამ ფლობ - ან, სულ უფრო ხშირად, საერთოდ არ არის საჯარო.

როგორც კი შეგიძლია თქვა, ამ სამი თვისებიდან რომელი გაკლია, წამალი ჩვეულებრივ ცხადია. დინამიკური და გჭირდება სტაბილურობა: გამოიყენე DNS. Shared და გჭირდება ექსკლუზიურობა: ეს არის იშვიათი შემთხვევა, რომელზეც ფულის გადახდა ღირს. საერთოდ არ არის საჯარო: ჰოსტინგ კომპანიისგან ნაყიდი ვერაფერი ამას გამოასწორებს, რადგან პრობლემა შენს პროვაიდერთანაა.

რას წყვეტს hostname და რას არა#

DNS ჩანაწერი მისამართს სახელად აქცევს, სახელების შეცვლა კი უფასოა. play.example.com დღეს ერთ მისამართზე შეიძლება მიუთითებდეს და მომდევნო კვირას სხვაზე, და ცვლილების ერთადერთი ფასი TTL-ია - წამების რაოდენობა, რომლის განმავლობაშიც resolver-ს ძველი პასუხის შენახვა შეუძლია.

ეს წყვეტს პრობლემას, რომლითაც ადამიანები სტატიკურ მისამართთან მიდიან:

• მოთამაშეები და მომხმარებლები აკრეფენ სახელს, რომელიც გაიხსენება, და არა ციფრებს.
• სერვერის გადატანა ერთხაზიანი რედაქტირებაა და არა შეტყობინება ყველასთვის.
• შეგიძლია რამდენიმე სერვისი საკუთარ სახელებზე გაუშვა და დამოუკიდებლად გადაიტანო.
• სერტიფიკატები სახელებზე გაიცემა, რასაც HTTPS რეალურად მოითხოვს.

რას არ წყვეტს:

• ყველაფერს, რაც მისამართს ამოწმებს და არა სახელს. allow-list ბანკში, ლიცენზიის სერვერი, კორპორატიული firewall-ის წესი: ყველა მათგანი მისამართს ხედავს და hostname გადაწყვეტილებაში არ მონაწილეობს.
• ყველაფერს DNS-მდე. მოწყობილობას, რომელიც მისამართით უნდა გაეწყოს, როგორიც არის ზოგიერთი VPN კლიენტი და სამრეწველო აღჭურვილობა.
• ქეშირებას. ერთსაათიანი TTL-ის მქონე ჩანაწერი შეცვლის შემდეგ საათით ძველია. დაბლა დაწიე TTL დაგეგმილ ცვლილებამდე ერთი დღით ადრე და მერე დააბრუნე. DNS ჩანაწერები ახსნილი დროს ფარავს, დომენის მიბმა გეიმ სერვერზე კი მისი დაყენების ათწუთიანი ვერსიაა.

კითხვა, რომელიც მისამართის ყიდვამდე უნდა დასვა, ასეთია: მჭირდება ჩემს კონფიგურაციაში რამეს რიცხვის ცოდნა თუ სახელი გამოდგება? გეიმ სერვერების, ვებსაიტებისა და აპლიკაციების აბსოლუტური უმრავლესობისთვის სახელი გამოდგება.

როდის არის გამოყოფილი მისამართი მართლა აუცილებელი#

ეს არის შემთხვევები. თუ მათში არ ხარ, ნუგეშს ყიდულობ.

სხვა შენ გამოგიყვანს allow-list-ში მისამართით. გადახდის პროვაიდერი, პარტნიორის API, კლიენტის კორპორატიული firewall, მართული ბაზა, რომელიც მხოლოდ ჩამოთვლილი წყაროებიდან იღებს კავშირებს. ყურადღებით გაითვალისწინე, რომ ეს შენს გამავალ წყაროს მისამართს ეხება, რაც იგივე არ არის, რაც მისამართი, რომელზეც შენი სერვერი მიიღწევა. shared ჰოსტზე გამავალი ტრაფიკი ჩვეულებრივ გადის shared მისამართიდან, რომელსაც ვერ აკონტროლებ და ვერ დაიფიცებ, რომ არ შეიცვლება. თუ ხელშეკრულება ფიქსირებულ წყაროს მისამართზეა დამოკიდებული, ეს ცხადად უნდა დადასტურდეს და არა ვარაუდით.

გჭირდება ცნობილი port, რომელიც უკვე დაკავებულია. Port-ები არის მექანიზმი, რომელიც რამდენიმე tenant-ს ერთ მისამართს ანაწილებინებს, და ეს მექანიზმი ვარდება, როცა port-ის ნომერი შეთანხმებადი არ არის. Port 25 შემომავალი ფოსტისთვის, port 53 საჯარო DNS სერვერისთვის, port 443 პროტოკოლისთვის, რომელიც HTTP არ არის და ამიტომ SNI-ით ვერ მარშრუტიზდება. თუ შენი სერვისი ნაგულისხმევ port-ზე უნდა იყოს და ნაგულისხმევი port დაკავებულია, გჭირდება მისამართი, სადაც ის თავისუფალია.

ფოსტას აგზავნი და გჭირდება მისამართის რეპუტაცია და rDNS. ფოსტის სერვერები აფასებენ გამგზავნ IP-ს და ამოწმებენ, რომ მისი reverse DNS ემთხვევა სახელს, რომელსაც ის აცხადებს. PTR ჩანაწერის დაყენება მისამართზე კონტროლს მოითხოვს, რაც მხოლოდ გამოყოფილთან გაქვს. ეს ერთადერთი ყველაზე კანონიერი მიზეზია მის საყიდლად - და პირდაპირ უნდა ითქვას, რომ RE:NODE ელფოსტას არ ჰოსტავს, ასე რომ თუ ეს შენი შემთხვევაა, ის ჩვენი შემთხვევა არ არის. SPF, DKIM და DMARC ახსნილი დანარჩენ კონფიგურაციას ფარავს.

საკუთარ nameserver-ებს უშვებ. Glue ჩანაწერები რეგისტრატორთან მისამართებია და სტაბილური უნდა იყოს.

ლიცენზია ან მოწყობილობა მისამართზეა მიბმული. ზოგიერთი კომერციული პროგრამა ლიცენზიას IP-ზე აბამს, ზოგი აპარატურული VPN კონფიგურაცია კი მისამართებით არის დაწერილი და არა სახელებით.

ეს არის სია. შეამჩნიე, რომ არც ერთი ჩანაწერი არ არის "გეიმ სერვერი".

როდის არ აქვს მნიშვნელობა#

შემთხვევები, რომლებსაც ყველაზე ხშირად ეკითხებიან, ისინია, სადაც გამოყოფილი მისამართი საერთოდ არაფერს ცვლის.

გეიმ სერვერი, რომელსაც hostname-ით უკავშირდებიან. მოთამაშეები აკრეფენ play.example.com:25565-ს ან იყენებენ SRV ჩანაწერს და მისამართს არასოდეს ხედავენ. კავშირის სტრიქონი უკვე შეიცავს port-ს, ამიტომ მისამართის სხვა tenant-ებთან გაზიარება არაფერი ჯდება. გეიმ სერვერის port-ები ახსნილი ფარავს, როგორ მუშაობს port-ების გამოყოფა და რატომ არის query port იმავე კითხვის ნაწილი.

ვებსაიტი reverse proxy-ს უკან. ეს ადრე გამოყოფილი მისამართის ყველაზე ძლიერი არგუმენტი იყო და SNI-მ დაასრულა. რადგან ყველა გამოყენებული ბრაუზერი TLS handshake-ში hostname-ს აგზავნის, ერთი მისამართი ნებისმიერი რაოდენობის სერტიფიკატს ემსახურება. გამოყოფილი მისამართი HTTPS-ისთვის 2026 წელს არაფერს გვაძლევს. რას აკეთებს reverse proxy მექანიზმს აღწერს.

საძიებო რეიტინგები. გამოყოფილ მისამართს რეიტინგში სარგებელი არ აქვს და ათწლეულზე მეტია არ ჰქონია. ვისაც ამ საფუძველზე მისი გაყიდვა სურს, სხვას ყიდის.

"რომ მეზობელმა ჩემი მისამართი არ დაბლოკვინოს." ფოსტისთვის ეს რეალური შიშია. ვებსაიტისთვის ან გეიმ სერვერისთვის ის ძირითადად თეორიულია: blocklist-ები, რომლებიც ვებ ტრაფიკისთვის მნიშვნელოვანია, დომენებსა და ქცევაზე მოქმედებს და არა shared ჰოსტინგის მისამართებზე, ხოლო მეზობლისკენ მიმართული მოცულობითი შეტევა არხს ავსებს, მისამართი shared იქნება თუ არა.

სერვერის მისამართის დამალვა. გამოყოფილი მისამართი უფრო იდენტიფიცირებადია და არა ნაკლებად. თუ მიზანი დაფარვაა, პასუხი არის proxy სერვისის წინ, და UDP თამაშისთვის ეს მაინც სერიოზული საქმეა.

დინამიკური მისამართები სახლში და dynamic DNS#

თუ საკუთარი კავშირიდან ჰოსტავ, მისამართი, რომელიც დღეს გაქვს, lease-ზეა. ის იცვლება, როცა როუტერი გადაიტვირთება, ხაზი თავიდან სინქრონიზირდება ან გრაფიკით, რომელსაც ზოგი პროვაიდერი მიზეზის გარეშე უშვებს და შენ მას არასოდეს გეტყვიან. ყველაფერი, რაც ძველ რიცხვზე მიუთითებდა, მუშაობას წყვეტს.

Dynamic DNS სტანდარტული პასუხია: პატარა კლიენტი შენს ქსელში ცვლილებას ამჩნევს და DNS ჩანაწერს API-ით ანახლებს. ჩანაწერის TTL დაბალია - 60 წამი ნორმალურია - რომ resolver-ებმა ახალი პასუხი სწრაფად აიღონ.

# What is my current public address, from two independent sources$ curl -4 https://ifconfig.co203.0.113.42$ dig +short myip.opendns.com @resolver1.opendns.com203.0.113.42# What does my hostname currently resolve to$ dig +short A home.example.com203.0.113.42

მომხმარებლის როუტერების უმეტესობას ჩაშენებული DDNS კლიენტი აქვს, სახელით Dynamic DNS ან DDNS, წინასწარ ჩამოთვლილი პროვაიდერებით. თუ შენსას არ აქვს, ddclient ან inadyn სერვერზე იმავეს აკეთებს, და რამდენიმე DNS პროვაიდერს აქვს დოკუმენტირებული update API, რომელსაც ხუთხაზიანი cron სკრიპტიდან გამოიძახებ.

რა ჯდება DDNS, პატიოსნად:

• ხარვეზი ყოველ ცვლილებაზე. მისამართის შეცვლასა და ჩანაწერის განახლებას შორის სახელი სხვისი კავშირისკენ მიუთითებს. ტიპურია წუთი-ორი; უფრო მეტი, თუ კლიენტი მხოლოდ ყოველ თხუთმეტ წუთში გამოკითხავს.
• სესიები არ მიჰყვება. უკვე დაკავშირებული მოთამაშეები მისამართს ელაპარაკებიან და არა სახელს. როცა ის იცვლება, ყველა წყდება და თავიდან უნდა შემოვიდეს. DNS ამას ვერაფერს უშლის.
• მოძველებული ქეში სადმე. resolver, რომელიც მოკლე TTL-ს უგულებელყოფს, ან მოთამაშე, რომლის კლიენტმაც მისამართი დაიმახსოვრა, ძველს კვლავ სცდის.

მეგობრებისთვის კერძო სერვერზე ეს სავსებით შესაძლებელია. ყველაფერზე, სადაც მოთამაშეები არ არიან შენს Discord-ში, ცვლა ის მიზეზია, რის გამოც ხალხი შემოსვლას წყვეტს. გეიმ სერვერის სახლში გაშვება თუ ქირაობა მთელ გარიგებას პატიოსნად აფასებს, იმ შემთხვევებისაც, როცა სახლში ჰოსტინგი იგებს.

CGNAT: როგორ გაარკვიო და რა გააკეთო#

არსებობს პრობლემის უარესი ვერსია და ის სულ უფრო გავრცელებულია: შენს კავშირს საჯარო მისამართი საერთოდ არ აქვს. Carrier-grade NAT ერთ საჯარო მისამართს ბევრ მომხმარებელს შორის ინაწილებს და "საჯარო" მისამართი შენს როუტერზე რეალურად პროვაიდერის ქსელის შიგნითაა. Port forward შეუძლებელია, რადგან port-ი შენი გადასამისამართებელი არ არის.

დიაგნოსტიკას ოცდაათი წამი სჭირდება. იპოვე WAN მისამართი შენი როუტერის სტატუსის გვერდზე და შეადარე იმას, რასაც ifconfig.co-ს მსგავსი საიტი აჩვენებს. თუ განსხვავდება, შენსა და ინტერნეტს შორის NAT დგას, რომელსაც ვერ აკონტროლებ. WAN მისამართი 100.64.0.0/10-ში არის უტყუარი ნიშანი - ეს დიაპაზონი სწორედ ამ მიზნისთვისაა დაცული. WAN ინტერფეისზე მისამართები 10.0.0.0/8-ში ან 192.168.0.0/16-ში იგივეს ნიშნავს.

# The address your router holds, from a machine on the LAN$ ip route get 1.1.1.1$ traceroute -n 1.1.1.1 | head -3

პირველი hop 100.64.x.x-ში, რომელსაც მოსდევს კიდევ პროვაიდერის hop-ები, სანამ რამე საჯაროა, იგივე აღმოჩენაა საპირისპირო მხრიდან.

შენი ვარიანტები, დაახლოებით იმის მიხედვით, რამდენად კარგად მუშაობს:

1. სთხოვე პროვაიდერს საჯარო მისამართი. ბევრი გასცემს მოთხოვნით, ხან უფასოდ, ხან მცირე ყოველთვიური გადასახადით ან ბიზნეს ტარიფით. ეს სუფთა გამოსწორებაა და სატელეფონო ზარს ღირს.
2. გამოიყენე IPv6. CGNAT არის IPv4-ის დეფიციტის პრობლემა და IPv6-ს ის არ აქვს. ხაფანგი ისაა, რომ შენს მოთამაშეებსაც სჭირდებათ IPv6, ბევრს კი ჯერ არ აქვს, ამიტომ მხოლოდ IPv6 სერვერი ხალხს ჩუმად გამორიცხავს. IPv6 და გეიმ სერვერები ფარავს, რამდენად შორს მიგიყვანს ეს დღეს.
3. გადაატარე მანქანაზე, რომელსაც საჯარო მისამართი აქვს. პატარა ქირავნობის სერვერი WireGuard ტუნელითა და port forward-ით თამაშის ტრაფიკს ატარებს. ეს მუშაობს, hop-ის ღირებულების ლატენტობას ამატებს და მეორე მანქანაა შესანახად. Tunnelling სერვისები იგივეს აკეთებენ HTTP-ისთვის ნაკლები მოწყობით და ჩვეულებრივ UDP-ს არ ატარებენ.
4. ამის ნაცვლად სერვერი იქირავე. ჰოსტინგზე სერვერს საჯარო მისამართი თავისთავად აქვს, რაც არის მთელი მიზეზი, რატომაც ეს პრობლემა არ ჩნდება.

ცხოვრება shared მისამართზე#

თუ shared ჰოსტინგზე ხარ, რამდენიმე პრაქტიკული შედეგი მოჰყვება და არცერთი არ არის დრამატული.

შენი port არის შენი იდენტობა. ერთ მისამართზე ორ სერვერს port-ის ნომრით განასხვავებენ, ამიტომ გეგმები აცხადებს, რამდენ გამოყოფას შეიცავს, და ერთის დამატება მისამართზე მეტ მნიშვნელობას იძენს.

გამავალი ტრაფიკი შეიძლება სხვა მისამართიდან გავიდეს, ვიდრე შემომავალი მოდის. თუ რაღაცამ უნდა გიშვას allow-list-ში, გამოსცადე და არ ივარაუდო, რომ მისამართი, რომელსაც პანელში ხედავ, ის არის, რასაც ისინი დაინახავენ.

Reverse DNS შენი არ არის. dig -x 203.0.113.10 დააბრუნებს იმას, რაც ჰოსტმა დააყენა, თუ დააყენა. ვერ შეცვლი, რაც ფოსტისთვის მნიშვნელოვანია და იმისთვის, რასაც უმეტესობა აკეთებს, არა.

მეზობლები უფრო მცირე პრობლემაა, ვიდრე ინტერნეტი ამბობს. სწორად გაშვებულ ჰოსტზე ერთი container მეორის ტრაფიკს ვერ ხედავს, CPU შეზღუდულია იმ წილზე, რაც იყიდე, და მეხსიერებამოკლებული container ჩერდება და არა მანქანის ჩამოთრევას აგრძელებს. რასაც shared მისამართი ნამდვილად გიჩენს, არის თანმდევი ზიანი სხვისკენ მიმართული ნაკადისგან, და ეს არხის თვისებაა და არა მისამართის.

RE:NODE-ზე ყოველი სერვერის მისამართი და port ნაჩვენებია მის გვერდზე პანელში, port-ები ემატება და იშლება Network ჩანართზე, query-სა და RCON-ის ჩათვლით, და ყოველი სერვერი საკუთარი container-ია საკუთარი მკაცრი CPU ლიმიტით. გამოყოფილი მისამართი კატალოგში ჩამოთვლილი არ არის, ამიტომ თუ შენი შემთხვევა ზემოთ ჩამოთვლილ ნამდვილთაგანია, ჯერ ჰკითხე და არ შეუკვეთო და არ იმედოვნო - პასუხი შეიძლება ის იყოს, რომ არ გჭირდება, და შეიძლება ის, რომ ამ კონკრეტული მოთხოვნისთვის ჩვენ სწორი ჰოსტი არ ვართ.

გადასვლა და რატომ არის სახელი რიცხვზე მნიშვნელოვანი#

დღეს, როცა ჰოსტს ცვლი ან გეგმას ისე ცვლი, რომ სერვერი გადადის, მისამართი იცვლება. ყველაფერი, რაც რიცხვს იცოდა, ტყდება; ყველაფერი, რაც სახელს იცოდა, ერთ DNS რედაქტირებას მისდევს.

რუტინა:

1. გადასვლამდე ერთი დღით ადრე დაწიე ჩანაწერის TTL 300 წამამდე.
2. დაელოდე ძველი TTL-ის ამოწურვას, რომ ყველა ქეშმა მოკლე აიღოს.
3. გადაიტანე მონაცემები ორივე სერვერის გაჩერებით.
4. შეცვალე ჩანაწერი და ძველი სერვერი რამდენიმე საათით მისაწვდომი დატოვე ისეთებისთვის, ვისაც მოძველებული პასუხი ან შენახული მისამართი აქვს.
5. დააბრუნე TTL მაღლა, როცა დაწყნარდება.

სერვერის გადატანა მოთამაშეების დაკარგვის გარეშე სრულ ვერსიას შეიცავს. ერთადერთი შეუქცევადი ნაწილია მოთამაშეები, რომლებმაც ნედლი მისამართი შეინახეს, და ეს არის არგუმენტი სახელის პირველივე დღიდან გაცემისთვის და არა იმ დღეს, როცა დაგჭირდება. ქვედომენები სერვერებისთვის ღირს წასაკითხად, თუ ერთზე მეტის გაშვებას ელი.

FAQ#

მჭირდება თუ არა static IP გეიმ სერვერისთვის?

თითქმის ნამდვილად არა. სერვერს მიეცი hostname და ის დაურიგე. მაშინ მისამართი შეიძლება შეიცვალოს ისე, რომ ვერავინ შეამჩნიოს, მოთამაშეები კი იღებენ რაღაცას, რაც დაიმახსოვრება. გამოყოფილი მისამართი არაფერს ამატებს კავშირს, რომელიც უკვე port-ის ნომერს შეიცავს.

რა განსხვავებაა static IP-სა და გამოყოფილ IP-ს შორის?

სტატიკური ნიშნავს, რომ მისამართი არ იცვლება. გამოყოფილი ნიშნავს, რომ მას სხვა არავინ იყენებს. ჰოსტინგზე მყოფი სერვერები ტიპურად არიან მისამართზე, რომელიც სტატიკურია, მაგრამ shared, რაც ფარავს თითქმის ყველა მოთხოვნას, რაც ადამიანებს აქვთ.

როგორ გავიგო, რომ CGNAT-ის უკან ვარ?

შეადარე WAN მისამართი შენი როუტერის სტატუსის გვერდზე იმას, რასაც საჯარო საიტი შენს მისამართად აჩვენებს. თუ განსხვავდება, ან თუ როუტერის WAN მისამართი 100.64.0.0/10-შია, carrier-grade NAT-ის უკან ხარ და port forwarding არ იმუშავებს.

შემიძლია dynamic DNS-ის გამოყენება სტატიკური მისამართის ნაცვლად?

დიახ და სახლის სერვერისთვის ეს ნორმალური პასუხია. კლიენტი DNS ჩანაწერს ანახლებს, როცა მისამართი იცვლება, მოკლე TTL-ით, რომ სწრაფად ამოქმედდეს. ელოდე მოკლე ხარვეზს ყოველ ცვლილებაზე და გათიშვას ყველასთვის, ვინც ამ დროს დაკავშირებულია.

მჭირდება გამოყოფილი IP SSL სერტიფიკატისთვის?

არა. SNI ერთ მისამართს ნებისმიერი რაოდენობის სერტიფიკატს აძლევინებს და ყველა გამოყენებული ბრაუზერი მას უჭერს მხარს. ეს მოთხოვნა წლების წინ გაქრა და ბევრ ძველ გვერდზე ისევ მეორდება.

shared მისამართი მიყენებს რისკს სხვა მომხმარებლების მხრიდან?

არა ისე, როგორც ადამიანები ელიან. Container-ები იზოლირებულია და CPU სერვერზეა შეზღუდული. ერთადერთი რეალური shared ექსპოზიცია არის არხისკენ მიმართული მოცულობითი შეტევა, რომელიც ყველას ეხება, როგორც არ უნდა იყოს მისამართები გამოყოფილი.