Naka-configure ang Nebula relay pero hindi ginagamit: tatlong setting na dapat suriin

Nagdagdag ka ng relay host, inilagay ang Nebula address nito sa isang configuration, at hindi pa rin nag-uusap ang dalawang peer. Nangyayari ito dahil kailangan ng relay path ng tatlong magkakahiwalay na pahayag na dapat magtugma, at isa lang sa mga ito ang nasa makina na malamang na inedit mo. Nasubaybayan ko ito nang dalawang beses: minsan ay hindi kailanman nabigyan ng relay role ang host na nagpapasa, at minsan ay nasa maling panig ng koneksyon ang mga setting. Sinusuri ng pagkakasunod-sunod sa ibaba ang role, ang anunsyo at ang pahintulot sa ganoong ayos, at bawat hakbang ay may command na nagsasabi kung dapat kang magpatuloy.

I-map ang tatlong role bago ka mag-edit ng configuration

Binibigyan ng Nebula ng gawain ang bawat host, at hindi namamana ang mga gawain. Sinasagot ng lighthouse ang mga tanong tulad ng nasaan ang peer na ito upang magkita-kita ang mga host. Nagpapasa ang relay ng trapiko sa pagitan ng dalawang peer na walang gumaganang direktang landas. Walang ginagawa ang ordinaryong host sa dalawa. Nasa tatlong magkaibang makina ang tatlong mahalagang setting, at kaya naman ang configuration ng client na mukhang kumpleto ay maaaring magpahintay sa dalawang peer.

# 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

Isang sintomas ang naghihiwalay sa dalawang klase ng kabiguan. Kung naglilista ang dalawang peer sa isa’t isa at nagpapakita ang log ng mga pagtatangkang handshake na hindi natatapos, gumagana ang discovery at ang data path ay hinaharangan ng NAT o ng firewall. Kung hindi talaga nalalaman ng isang peer ang address ng isa, nasa lighthouse o sa static host map nito ang problema, at hindi ito kayang ayusin ng relay settings.

Kumpirmahin kung aling configuration ang aktwal na na-load ng bawat host bago mo baguhin ang anumang iba. Ang unit na nagbabasa ng ibang path kaysa sa file na inedit mo ay karaniwan at nakakahiyang dahilan ng „walang ginawa ang pagbabago”:

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

Mahalaga ang version line sa magkahalong fleet. Ang paghawak ng relay, ugali ng punching at mga tinatanggap na configuration key ay hindi pareho sa mga release, kaya huwag ipagpalagay na nauunawaan ng mas lumang build ang isang seksyong hindi para dito isinulat. Ihanay ang mga host sa parehong minor series, pagkatapos ay patakbuhin ang nebula -test -config /etc/nebula/config.yml sa bawat host at ihambing ang output bago mo i-debug ang transport na hindi ipinapatupad ng code.

Paganahin ang forwarding role sa relay host

Ang relay role ay isang flag sa forwarding host, at hiwalay ito sa pagiging lighthouse. Ang host na naka-on ang discovery at naka-off ang relay forwarding ay nananatiling discovery service lamang. Sa relay:

relay:
  am_relay: true

Nagpapahayag ng layunin ang flag na iyon; hindi ito lumilikha ng maabot. Kailangang maabot ang relay mula sa dalawang peer, na sa praktika ay nangangahulugang pampublikong address, papasok na UDP sa Nebula port na bukas sa firewall ng host at sa anumang cloud security group, at walang double NAT sa harap nito. Suriin ang socket na nakikinig at pagkatapos ay panoorin kung dumarating ang mga packet ng peer:

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

Dalawang limitasyon ang makakatipid ng oras mamaya. Hindi maabot ang relay sa pamamagitan ng ibang relay, kaya ang chain ng relay names sa configuration ay hindi kapalit ng magagamit na landas papunta sa forwarding host. At nagpapasa ng packet ang relay; hindi ito nagbibigay ng pahintulot, ang mga papasok na patakaran ng destinasyon pa rin ang nagpapasya kung pinapayagan ang ipinapasang daloy. Ang role at mga kinakailangan nito ay nakasaad sa dokumentasyon ng configuration ng relay.

I-anunsyo ang relay mula sa destinasyon, hindi mula sa client

Ito ang pagbaliktad na kumakain ng pinakamaraming oras. Ang relay list ay nabibilang sa host na sinusubukan mong maabot, dahil sinasabi nito sa ibang peer kung aling relay ang maaaring gamitin upang maabot ang host na iyon. Ang ilagay ito sa client na nagsisimula ng koneksyon ay walang ginagawa para sa direksyong kailangan ng client:

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

Iniulat ng mga peer ang listahang iyon kasama ng kanilang mga address kapag nag-check in sila sa lighthouse, kaya kumakalat ang anunsyo sa pamamagitan ng discovery at hindi sa direktang palitan. Kung hindi maabot ng destinasyon ang anumang lighthouse, hindi kailanman kumakalat ang relay list nito at nananatiling idle ang tamang naka-configure na relay. Ang kabiguan na iyon ay mukhang eksaktong sirang relay at hindi naman.

Bigyan ang destinasyon ng bootstrap path sa parehong pagdaan. Itinatali ng static host map ang Nebula address sa pampublikong endpoint upang may mapuntahan ang unang handshake, at kailangan nito ng entry para sa relay kung tatanggapin ng destinasyon ang ipinapasang trapiko mula sa mga host na hindi nito direktang maabot:

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

Hayaang gamitin ng kumokonektang peer ang relay

Kailangan ng panig na nagsisimula ng sarili nitong pahintulot. Naka-on bilang default ang relay.use_relays, kaya ang kaso na sulit hanapin ay ang tahasang false, madalas na kinopya mula sa template na isinulat bago umiral ang relay feature o iniwan ng naunang pagtatangkang pilitin ang direktang landas:

relay:
  use_relays: true

Ang pahintulot sa panig na ito ay hindi lamang ang gate. Naaangkop pa rin ang mga papasok na patakaran ng destinasyon sa ipinapasang packet, at ang source na itinatapat nila ay ang identity sa loob ng tunnel at hindi ang address ng relay mismo. Kapag natapos ang ipinapasang handshake at nabigo pa rin ang application, basahin ang log ng destinasyon para sa source na naitala nito bago mo muling isulat ang isang patakaran.

Ang mga setting ng NAT traversal ay nakikipag-ugnayan sa lahat ng ito. Tumutulong ang punchy.punch sa dalawang peer na magbukas ng direktang landas, at kapag nagtagumpay ito ay walang relay traffic na mapapansin; tagumpay iyon, hindi nawawalang relay. Ang pares na paminsan-minsan lang gumagana ay karaniwang nangangahulugang paminsan-minsan lang nagtatagumpay ang punching, kaya subukan ang pares na iyon nang ilang beses sa halip na maghinuha mula sa isang pagtatangka.

I-verify sa pares na nabigo, pagkatapos ay i-reload

Subukan ang dalawang host na talagang nabigo, kasama ang application na kailangan nila. Ang matagumpay na ping mula sa iyong workstation patungo sa serbisyo ng relay mismo ay walang pinapatunayan tungkol sa pagpapasa sa pagitan ng dalawang iba pang peer, at ito ang pinakakaraniwang false positive sa buong pamamaraang ito.

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

I-reload sa halip na i-restart, at kumpirmahin na nakuha ng tumatakbong proseso ang file na inedit mo. Binabaligtad ng restart ang bawat tunnel at pinapahirapan ang pagbasa ng susunod na pagsubok, samantalang pinapanatili ng SIGHUP ang proseso at pinababasa muli ito ng configuration:

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

Gumagana lang ang systemctl reload kapag tinukoy ng lokal na unit ang ExecReload, at hindi ito ginagawa ng unit na kasama ng proyekto, kaya ang systemctl kill -s HUP ang hakbang na nagtatagumpay sa karaniwang install. Pagkatapos ng reload, basahin ang journal para sa configuration path na binuksan ng proseso, upang malaman mo na ang bagong file ang nabasa at hindi ang inakala mong naka-load.

Parehong kumikilos ang relay settings at NAT punching sa landas; wala sa kanila ang kumikilos sa identity. Kung nabigo pa rin ang pares sa handshake kapag kumpirmado na ang am_relay, relays at use_relays sa tumatakbong configuration, suriin kung nagpapakita ang dalawang host ng mga certificate na inisyu para sa mga pangalang ginagamit nila at kung pareho ang CA sa dalawang panig. Panatilihing hindi nagbabago ang configuration ng certificate at firewall habang isa-isang binabago ang isang transport setting, dahil ang pagbabago ng certificate at pagbabago ng relay sa parehong pagsubok ay walang sinasabi tungkol sa kung alin ang gumalaw ng handshake. Nabigo ang hindi pagtutugma ng pangalan o CA sa parehong lugar tulad ng relay na hindi kailanman natagpuan, at kaya bahagi ng parehong pagdaan ang kontra-suring ito.

Pagkatapos ay kumpirmahin na nasa file na kinabibilangan nito ang bawat pahayag:

• am_relay: true sa forwarding host, at maabot ang host na iyon sa UDP mula sa dalawang panig.
• relays: kasama ang Nebula address ng host na iyon sa destinasyon.
• use_relays: true sa peer na nagsisimula ng koneksyon.
• Mga papasok na patakaran sa destinasyon na pinapayagan pa rin ang tunay na source pagkatapos magbago ang landas.