Nebula-relay määritetty mutta käyttämätön: kolme asetusta tarkistettavaksi

Lisäsit relay-isännän, laitoit sen Nebula-osoitteen määritykseen, eivätkä kaksi vertaisparia silti puhu toisilleen. Näin käy, koska relay-reitti vaatii kolme erillistä lausumaa, joiden on sovittava yhteen, ja vain yksi niistä on koneella, jota todennäköisesti muokkasit. Olen selvittänyt tätä kahdesti: kerran välityskoneelle ei ollut koskaan annettu relay-roolia, ja kerran asetukset oli kirjoitettu yhteyden väärälle puolelle. Alla oleva järjestys tarkistaa roolin, ilmoituksen ja luvan siinä järjestyksessä, ja jokaisessa vaiheessa on komento, joka kertoo, pitääkö jatkaa.

Kartoita kolme roolia ennen kuin muokkaat määritystä

Nebula antaa jokaiselle isännälle tehtävän, eivätkä tehtävät periydy. Lighthouse vastaa kysymyksiin siitä, missä tämä vertaispari on, jotta isännät löytävät toisensa. Relay välittää liikennettä kahden vertaisparin välillä, joilla ei ole toimivaa suoraa reittiä. Tavallinen isäntä ei tee kumpaakaan. Kolme ratkaisevaa asetusta ovat kolmella eri koneella, ja siksi täydelliseltä näyttävä asiakasmääritys voi jättää molemmat vertaisparit odottamaan.

# on the discovery host
lighthouse:
  am_lighthouse: true
  hosts: []

# on every other host, point at the discovery host's Nebula address
lighthouse:
  hosts:
    - 10.42.0.1

Yksi oire erottaa kaksi virheluokkaa. Jos molemmat vertaisparit listaavat toisensa ja loki näyttää kättelyyrityksiä, jotka eivät koskaan valmistu, löytö toimii ja datareitin estää NAT tai palomuuri. Jos vertaispari ei koskaan saa toisen osoitetta selville, ongelma on lighthousessa tai sen staattisessa isäntäkartassa, eivätkä relay-asetukset korjaa sitä.

Varmista, minkä määrityksen kukin isäntä todella latasi, ennen kuin muutat mitään muuta. Unit, joka lukee eri polkua kuin muokkaamasi tiedosto, on yleinen ja kiusallinen syy siihen, että „muutos ei tehnyt mitään”:

systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager

Versiorivillä on merkitystä sekalaisessa laivueessa. Relayn käsittely, punch-käyttäytyminen ja hyväksytyt määritysavaimet eivät ole samanlaisia eri julkaisuissa, joten älä oleta, että vanhempi koontiversio ymmärtää osion, jota varten sitä ei kirjoitettu. Aseta isännät samaan minor-sarjaan, aja sitten nebula -test -config /etc/nebula/config.yml jokaisella isännällä ja vertaa tulostetta ennen kuin alat selvittää siirtoa, jota koodi ei toteuta.

Ota välitysrooli käyttöön relay-isännällä

Relay-rooli on yksi lippu välityskoneella, ja se on erillinen lighthousena olemisesta. Isäntä, jolla löytö on päällä ja relay-välitys pois, on edelleen vain löytöpalvelu. Relaylla:

relay:
  am_relay: true

Lippu ilmoittaa aikomuksen; se ei luo tavoitettavuutta. Relayn on oltava tavoitettavissa molemmista vertaisparista, mikä käytännössä tarkoittaa julkista osoitetta, saapuvaa UDP:tä Nebula-portissa, joka on auki isännän palomuurissa ja missä tahansa pilven suojausryhmässä, eikä kaksinkertaista NATia sen edessä. Tarkista kuunteleva socket ja seuraa sitten, saapuvatko vertaisparin paketit:

ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7

Kaksi rajaa säästää aikaa myöhemmin. Relaylle ei pääse toisen relayn kautta, joten määrityksen relay-nimien ketju ei korvaa käyttökelpoista reittiä välityskoneelle. Ja relay välittää paketteja; se ei myönnä lupaa, kohteen omat saapuvat säännöt päättävät edelleen, sallitaanko välitetty virta. Rooli ja sen vaatimukset on esitetty relayn määritysohjeissa.

Ilmoita relay kohteesta, älä asiakkaasta

Tämä on se käänteisyys, joka syö eniten tunteja. Relay-luettelo kuuluu isännälle, jota yrität tavoittaa, koska se kertoo muille vertaispareille, mitä relayja kyseisen isännän tavoittamiseen saa käyttää. Sen laittaminen yhteyden avaavaan asiakkaaseen ei tee mitään siihen suuntaan, jota asiakas tarvitsee:

# on the DESTINATION host: relays others may use to reach me
relay:
  relays:
    - 10.42.0.5

Vertaisparit ilmoittavat luettelon osoitteidensa mukana, kun ne käyvät ilmoittautumassa lighthousella, joten ilmoitus leviää löydön kautta eikä suoran vaihdon kautta. Jos kohde ei tavoita lighthousia, sen relay-luettelo ei koskaan leviä ja oikein määritetty relay pysyy toimettomana. Se vika näyttää täsmälleen rikkinäiseltä relaylta eikä ole sitä.

Anna kohteelle käynnistysreitti samassa vaiheessa. Staattinen isäntäkartta sitoo Nebula-osoitteen julkiseen päätepisteeseen, jotta ensimmäisellä kättelyllä on minne mennä, ja se tarvitsee merkinnän relaylle, jos kohteen on hyväksyttävä välitettyä liikennettä isänniltä, joita se ei tavoita suoraan:

static_host_map:
  "10.42.0.5": ["203.0.113.10:4242"]

Anna yhdistävän vertaisparin käyttää relayta

Aloittava puoli tarvitsee oman lupansa. relay.use_relays on oletuksena päällä, joten etsinnän arvoinen tapaus on nimenomainen false, usein kopioitu mallipohjasta, joka kirjoitettiin ennen relay-ominaisuutta tai jätetty aiemmasta yrityksestä pakottaa suoria reittejä:

relay:
  use_relays: true

Tämän puolen lupa ei ole ainoa portti. Kohteen saapuvat säännöt koskevat edelleen välitettyä pakettia, ja lähde, johon niitä verrataan, on tunnelin sisäinen identiteetti eikä relayn oma osoite. Kun välitetty kättely valmistuu ja sovellus epäonnistuu silti, lue kohteen lokista lähde, jonka se kirjasi, ennen kuin kirjoitat säännön uudelleen.

NAT-läpäisyasetukset vaikuttavat tähän kaikkeen. punchy.punch auttaa kahta vertaisparia avaamaan suoran reitin, ja kun se onnistuu, relay-liikennettä ei ole havaittavissa; se on onnistuminen, ei puuttuva relay. Pari, joka toimii ajoittain, tarkoittaa yleensä sitä, että punch onnistuu vain joskus, joten testaa sitä paria useita kertoja sen sijaan, että tekisit johtopäätöksen yhdestä yrityksestä.

Varmista parilla, joka epäonnistui, ja lataa sitten uudelleen

Testaa ne kaksi isäntää, jotka todella epäonnistuivat, niiden tarvitsemalla sovelluksella. Onnistunut ping työasemastasi relayn omaan palveluun ei todista mitään välityksestä kahden muun vertaisparin välillä, ja se on yleisin väärä positiivinen koko tässä menettelyssä.

journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9

Lataa uudelleen sen sijaan että käynnistäisit uudelleen, ja varmista, että käynnissä oleva prosessi otti muokkaamasi tiedoston. Uudelleenkäynnistys repii jokaisen tunnelin ja tekee seuraavasta testistä vaikeammin luettavan, kun taas SIGHUP säilyttää prosessin ja saa sen lukemaan määrityksen uudelleen:

sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)

systemctl reload toimii vain, kun paikallinen unit määrittelee ExecReloadin, eikä projektin mukana tuleva unit tee niin, joten systemctl kill -s HUP on vaihe, joka onnistuu vakioasennuksessa. Lue uudelleenlatauksen jälkeen journalista määrityspolku, jonka prosessi avasi, jotta tiedät, että uusi tiedosto luettiin eikä se, jonka luulit olevan ladattu.

Relay-asetukset ja NAT-punch vaikuttavat molemmat reittiin; kumpikaan ei vaikuta identiteettiin. Jos pari epäonnistuu kättelyssä edelleen, kun am_relay, relays ja use_relays on vahvistettu käynnissä olevassa määrityksessä, tarkista, että molemmat isännät esittävät sertifikaatit, jotka on myönnetty nimille, joilla ne on määritetty, ja että CA on sama molemmilla puolilla. Pidä sertifikaatti- ja palomuurimääritys muuttumattomana, kun muutat yhtä siirtoasetusta kerrallaan, sillä sertifikaattimuutos ja relaymuutos samassa testissä eivät kerro, kumpi niistä siirsi kättelyn. Nimi- tai CA-poikkeama epäonnistuu samassa paikassa kuin relay, jota ei koskaan löytynyt, ja siksi tämä vastatarkistus kuuluu samaan vaiheeseen.

Vahvista sitten, että jokainen lausuma on tiedostossa, johon se kuuluu:

• am_relay: true välityskoneella, ja kyseinen isäntä tavoitettavissa UDP:llä molemmilta puolilta.
• relays: kyseisen isännän Nebula-osoitteella kohteessa.
• use_relays: true vertaisparilla, joka avaa yhteyden.
• Kohteen saapuvat säännöt, jotka sallivat edelleen todellisen lähteen reittimuutoksen jälkeen.