Katra bāka var pastāstīt resursdatoram par katru citu partneri, izņemot to, kur atrodas pati bāka. Kaut kam jābūt zināmam pirms overlay pastāv, un Nebula šo kaut ko ievieto vienā mazā kartē. Karte pāro overlay identitāti ar adresi, kas darbojas parastajā tīklā. Viss, kas tiek iemācīts vēlāk, ir atkarīgs no tā, vai šis pāris ir pareizs.

Divas adreses ar diviem uzdevumiem

Katram Nebula resursdatoram ir overlay adrese, kas paliek nemainīga, kamēr ierīce pārvietojas starp tīkliem. Šī adrese ir identitāte, ko izmanto sertifikāti, ugunsmūra noteikumi un partneru attiecības, un viena pati tā nekur nemaršrutē. Sasniedzamais galapunkts ir kaut kas cits: resursdatora vārds vai adrese apakštīklā plus UDP ports, un tas mainās ikreiz, kad iekārta maina atrašanās vietu. Statiskā karte ir savienojums starp abiem.

Kartē iekļauj tikai tos resursdatorus, kas jāizsauc auksti, kas parasti nozīmē bākas un varbūt vienu releju. Saraksta īsuma saglabāšana ir dizaina mērķis, jo katrs manuālais ieraksts kļūst par faktu, kas kādam jāuztur. Abu adrešu tipu sajaukšana ir ierastā konfigurācijas kļūda: publiska adrese, kas ievietota bāku sarakstā, neuzsāk atklāšanu.

Identitāte iet tur, kur tiek gaidīta identitāte. Sasniedzamība iet kartē.

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

Kartes ieraksta anatomija

Atslēga ir overlay adrese, kas rakstīta kā virkne pēdiņās, un vērtība ir galapunktu saraksts, tāpēc vienai identitātei var būt vairāki ieejas punkti. Katrs galapunkts nes resursdatoru un portu, un portam jāatbilst tam, ko otra puse faktiski klausās. Nebula noklusējums ir UDP 4242, kas ir sākumpunkts, nevis solījums par jūsu izvietojumu.

Vairāki galapunkti ir noderīgi, ja bākai ir vairāk nekā viens ceļš uz iekšu, piemēram, publiska adrese un privāta adrese resursdatoriem tajā pašā segmentā. Klients tos izmēģina pēc kārtas, tāpēc uzticamāko lieciet pirmo. IPv6 gadījumā ievietojiet adresi kvadrātiekavās pirms porta pievienošanas; kļūdīšanās rada parsēšanas kļūdu, kas norāda uz nepareizo rindu.

Nepareizs ports rada klusumu, nevis kļūdu, jo UDP nav rokasspiediena, ar ko atteikt. Tāpēc ieraksta formātu ir vērts pārbaudīt pret Nebula static_host_map atsauci nevis atmiņu. Atsauce aptver arī galapunktu sarakstus un DNS atjaunināšanas uzvedību.

Sāknēšanai jādarbojas pirms overlay

DNS vārdam kartē ir jāatrisinās ar to atrisinātāju, kas resursdatoram ir pirms jebkura tuneļa, tas ir, parasto sistēmas atrisinātāju. Pārbaudiet to no tās pašas mašīnas, sāknēšanas laikā, ar apturētu overlay. Vārds, kas atrisinās tikai ar paša overlay DNS, nevar sāknēt overlay. Tas pats tests attiecas uz maršrutu: ugunsmūra noteikums, kas atļauj overlay, bet ne pirmo UDP apmaiņu, bloķē sākotnējo paketi.

Pārbaudiet portu ar UDP rīku, nevis pieņemot, ka tas ir atvērts. Apstipriniet, ka jebkura portu pāradresācija ceļā norāda uz pareizo iekšējo resursdatoru un ka pastāv atgriešanās ceļš. Ja resursdatora vārds atrisinās uz vairākām adresēm, pārbaudiet katru, jo klients var izvēlēties adresi, kuru jūs nekad neesat pārbaudījis.

Statiskie ieraksti tiek izsaukti tieši un nekad neprasa bākai. Tāpēc kļūme šeit izskatās kā parasts taimauts bez neviena partnera.

Kas notiek pēc pirmā rokasspiediena

Kad resursdators sasniedz bāku, tas uzzina par partneriem un viņu sasniedzamajām adresēm bez papildu manuāliem ierakstiem. Resursdatori, kas ir pārvietojušies kopš pēdējā savienojuma, kļūst atklājami pa šo kanālu. Tas ir atlīdzība par manuālās kartes turēšanu mazu.

Resursdatori var arī paziņot savas papildu sasniedzamās adreses, un tā partneris aiz zināmas publiskas adreses palīdz citiem to atrast. Šie paziņojumi tiek iemācīti, nevis ierakstīti statiskajā kartē.

Atjaunināšanas uzvedība ir svarīga galapunktiem, kas rakstīti kā DNS vārdi, jo atrisinātā adrese var mainīties, kamēr process turpina darboties. Nebula iestatījumi kontrolē, kā šie meklējumi notiek, tostarp kurš atrisinātājs tiek izmantots, tāpēc lasiet tos, nevis pieņemiet sistēmas noklusējumu. Resursdatorā, kura atrisinātājs mainās, kad paceļas tunelis, nepareizs iestatījums var pārvērst strādājošu sāknēšanu vārdā, kas pārstāj atrisināties sesijas vidū. Meklējuma piesaistīšana stabilam atrisinātājam bieži ir atšķirība starp uzticamu overlay un periodisku.

Kad atklāšana darbojas, bet viens partneris ne

Ja bākas ir sasniedzamas un lielākā daļa partneru savienojas, sāknēšana nav problēma. Atlikušais pāris vai nu nevar atrast lietojamu ceļu viens pie otra, vai cieš neveiksmi virs sasniedzamības. Vēl viena bākas adreses rakstības pievienošana nevar salabot nevienu no abiem gadījumiem.

Pārbaudiet pāri pirms kartes rediģēšanas, uz kuras jau balstās viss pārējais. Kartes maiņa traucē katram resursdatoram, tāpēc tas ir pēdējais, kam jāpieskaras, nevis pirmais.

Sāciet ar tās pašas iestādes sertifikātiem, jo noraidīts rokasspiediens no tālienes var izskatīties kā nesasniedzams partneris. Pēc tam pārbaudiet, vai pāris var izveidot tiešu ceļu un vai relejs ir konfigurēts tīkliem, kas atsakās no tiešas datplūsmas. Relejs pievieno lēcienu un atkarību, bet tā ir atbalstīta atbilde, un pāra ceļa labošana ir cits uzdevums nekā atklāšanas labošana.

Saistītie raksti