Relay Nebula wedi’i ffurfweddu ond heb ei ddefnyddio: tri gosodiad i’w gwirio
Mae llwybr relay angen tair datganiad sy’n cytuno ar dri gwesteiwr. Gwiriwch rôl y relay, rhestr relay’r gyrchfan a chaniatâd y cymar yn gyntaf.
Gwnaethoch ychwanegu gwesteiwr relay, rhoi ei gyfeiriad Nebula mewn ffurfweddiad, ac mae’r ddau gymar yn dal heb siarad â’i gilydd. Mae hynny’n digwydd oherwydd bod llwybr relay angen tair datganiad ar wahân sy’n gorfod cytuno, a dim ond un ohonynt sydd ar y peiriant a olygwyd gennych yn ôl pob tebyg. Rwyf wedi dilyn hyn ddwywaith: unwaith lle nad oedd y gwesteiwr anfon erioed wedi cael rôl y relay, ac unwaith lle roedd y gosodiadau wedi’u hysgrifennu ar ochr anghywir y cysylltiad. Mae’r dilyniant isod yn gwirio’r rôl, y cyhoeddiad a’r caniatâd yn y drefn honno, ac mae gan bob cam orchymyn sy’n dweud wrthych a ddylech barhau.
Mapiwch y tair rôl cyn i chi olygu ffurfweddiad
Mae Nebula yn rhoi swydd i bob gwesteiwr, ac nid yw’r swyddi’n cael eu hetifeddu. Mae lighthouse yn ateb cwestiynau fel ble mae’r cymar hwn fel y gall gwesteiwyr ddod o hyd i’w gilydd. Mae relay yn anfon traffig rhwng dau gymar heb lwybr uniongyrchol gweithredol. Nid yw gwesteiwr cyffredin yn gwneud y naill na’r llall. Mae’r tri gosodiad sy’n bwysig yn byw ar dri pheiriant gwahanol, a dyna pam y gall ffurfweddiad cleient sy’n edrych yn gyflawn adael y ddau gymar yn aros.
# 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
Mae un symptom yn gwahanu’r ddau ddosbarth methiant. Os yw’r ddau gymar yn rhestru’i gilydd ac mae’r log yn dangos ymdrechion handshake nad ydynt byth yn gorffen, mae’r darganfyddiad yn gweithio ac mae’r llwybr data wedi’i rwystro gan NAT neu gan wal dân. Os nad yw cymar byth yn dysgu cyfeiriad y llall o gwbl, y lighthouse neu ei fap gwesteiwyr statig sydd ar fai, ac ni all gosodiadau relay drwsio hynny.
Cadarnhewch pa ffurfweddiad a lwythodd pob gwesteiwr mewn gwirionedd cyn newid unrhyw beth arall. Mae uned sy’n darllen llwybr gwahanol i’r ffeil a olygwyd gennych yn achos cyffredin a chywilyddus o „ni wnaeth y newid unrhyw beth”:
systemctl cat nebula | grep ExecStart
nebula -version
journalctl -u nebula -n 20 --no-pager
Mae’r llinell fersiwn yn bwysig mewn fflyd gymysg. Nid yw trin relay, ymddygiad punchio a’r allweddi ffurfweddiad a dderbynnir yn union yr un fath ar draws rhyddiadau, felly peidiwch â chymryd yn ganiataol bod adeilad hŷn yn deall adran na chafodd ei hysgrifennu ar ei chyfer. Aliniwch y gwesteiwyr ar yr un gyfres leiaf, yna rhedwch nebula -test -config /etc/nebula/config.yml ar bob gwesteiwr a chymharwch yr allbwn cyn dadfygio cludiant nad yw’r cod yn ei weithredu.
Galluogwch y rôl anfon ar y gwesteiwr relay
Mae rôl y relay yn un faner ar y gwesteiwr anfon, ac mae’n annibynnol ar fod yn lighthouse. Nid yw gwesteiwr â darganfyddiad wedi’i alluogi ac anfon relay wedi’i analluogi ond yn dal i fod yn wasanaeth darganfod yn unig. Ar y relay:
relay:
am_relay: true
Mae’r faner honno’n datgan bwriad; nid yw’n creu cyrhaeddedd. Rhaid i relay fod yn gyrhaeddadwy o’r ddau gymar, sydd yn ymarferol yn golygu cyfeiriad cyhoeddus, UDP i mewn ar borth Nebula ar agor yn wal dân y gwesteiwr ac mewn unrhyw grŵp diogelwch cwmwl, a dim NAT dwbl o’i flaen. Gwiriwch y soced sy’n gwrando ac yna gwyliwch am becynnau’r cymar yn cyrraedd:
ss -lunp | grep nebula
tcpdump -ni any udp port 4242 and host 198.51.100.7
Mae dau derfyn yn arbed amser yn ddiweddarach. Ni ellir cyrraedd relay trwy relay arall, felly nid yw cadwyn o enwau relay mewn ffurfweddiad yn cymryd lle rhoi llwybr defnyddiadwy i’r gwesteiwr anfon. Ac mae relay yn anfon pecynnau; nid yw’n rhoi caniatâd, mae rheolau i mewn y gyrchfan ei hun yn dal i benderfynu a yw’r ffrwd a anfonwyd yn cael ei chaniatáu. Mae’r rôl a’i gofynion wedi’u nodi yn y dogfennaeth ffurfweddu relay.
Cyhoeddwch y relay o’r gyrchfan, nid o’r cleient
Dyma’r gwrthdro sy’n bwyta’r nifer fwyaf o oriau. Mae’r rhestr relay yn perthyn i’r gwesteiwr rydych yn ceisio ei gyrraedd, oherwydd mae’n dweud wrth gymariaid eraill pa relaid y gellir eu defnyddio i gyrraedd y gwesteiwr hwnnw. Nid yw ei rhoi ar y cleient sy’n cychwyn y cysylltiad yn gwneud unrhyw beth i’r cyfeiriad sydd ei angen ar y cleient:
# on the DESTINATION host: relays others may use to reach me
relay:
relays:
- 10.42.0.5
Mae cymariaid yn adrodd y rhestr honno ynghyd â’u cyfeiriadau pan fyddant yn cofrestru gyda’r lighthouse, felly mae’r cyhoeddiad yn lledaenu trwy’r darganfyddiad yn hytrach na thrwy gyfnewid uniongyrchol. Os na all y gyrchfan gyrraedd lighthouse, ni fydd ei rhestr relay byth yn lledaenu ac mae relay sydd wedi’i ffurfweddu’n gywir yn parhau’n segur. Mae’r methiant hwnnw’n edrych yn union fel relay wedi torri ac nid yw.
Rhowch lwybr cychwyn i’r gyrchfan yn yr un pas. Mae’r map gwesteiwyr statig yn clymu cyfeiriad Nebula i ben draw cyhoeddus fel bod gan y handshake cyntaf rywle i fynd, ac mae angen cofnod arno ar gyfer y relay os yw’r gyrchfan i dderbyn traffig a anfonwyd o westeiwyr na all eu cyrraedd yn uniongyrchol:
static_host_map:
"10.42.0.5": ["203.0.113.10:4242"]
Gadewch i’r cymar sy’n cysylltu ddefnyddio’r relay
Mae ar yr ochr gychwynnol angen ei chaniatâd ei hun. Mae relay.use_relays ymlaen yn ddiofyn, felly’r achos sy’n werth ei hela yw false penodol, yn aml wedi’i gopïo o dempled a ysgrifennwyd cyn bodolaeth y nodwedd relay neu wedi’i adael gan ymgais gynharach i orfodi llwybrau uniongyrchol:
relay:
use_relays: true
Nid yw caniatâd ar yr ochr hon yr unig giât. Mae rheolau i mewn y gyrchfan yn dal i fod yn berthnasol i’r pecyn a anfonwyd, a’r ffynhonnell y cânt eu cymharu â hi yw’r hunaniaeth y tu mewn i’r twnnel ac nid cyfeiriad y relay ei hun. Pan fydd y handshake a anfonwyd wedi gorffen ac mae’r cymhwysiad yn dal i fethu, darllenwch log y gyrchfan am y ffynhonnell a gofnodwyd ganddi cyn ailysgrifennu rheol.
Mae gosodiadau trawstorri NAT yn rhyngweithio â hyn i gyd. Mae punchy.punch yn helpu dau gymar i agor llwybr uniongyrchol, a phan fydd yn llwyddo nid oes unrhyw draffig relay i’w arsylwi; llwyddiant yw hynny, nid relay ar goll. Mae pâr sy’n gweithio’n ysbeidiol fel arfer yn golygu bod punchio’n llwyddo weithiau, felly profwch y pâr hwnnw sawl gwaith yn lle dod i gasgliad o un ymgais.
Gwiriwch gyda’r pâr a fethodd, ac yna ail-lwythwch
Profwch y ddau westeiwr a fethodd mewn gwirionedd, gyda’r cymhwysiad sydd eu hangen arnynt. Nid yw ping llwyddiannus o’ch gorsaf waith i wasanaeth y relay ei hun yn profi unrhyw beth am anfon rhwng dau gymar arall, a dyma’r ffug-bositif mwyaf cyffredin yn y weithdrefn gyfan hon.
journalctl -u nebula -f | grep -iE "relay|handshake"
ping -c 3 10.42.0.9
Ail-lwythwch yn lle ailgychwyn, a chadarnhewch fod y broses sy’n rhedeg wedi codi’r ffeil a olygwyd gennych. Mae ailgychwyn yn rhwygo pob twnnel ac yn gwneud y prawf nesaf yn anoddach ei ddarllen, tra bod SIGHUP yn cadw’r broses ac yn gwneud iddi ailddarllen y ffurfweddiad:
sudo systemctl kill -s HUP nebula
# same signal when nebula runs in the foreground
kill -HUP $(pidof nebula)Nid yw systemctl reload yn gweithio ond pan fydd yr uned leol yn diffinio ExecReload, ac nid yw’r uned a gyflenwir gyda’r prosiect yn gwneud hynny, felly systemctl kill -s HUP yw’r cam sy’n llwyddo ar osodiad safonol. Ar ôl yr ail-lwytho, darllenwch y journal ar gyfer y llwybr ffurfweddiad a agorwyd gan y broses, fel y gwyddoch mai’r ffeil newydd a ddarllenwyd ac nid yr un y gwnaethoch dybio ei bod wedi’i llwytho.
Mae gosodiadau relay a phunchio NAT ill dau yn gweithredu ar y llwybr; nid yw’r naill na’r llall yn gweithredu ar hunaniaeth. Os yw’r pâr yn dal i fethu ei handshake unwaith y bydd am_relay, relays a use_relays wedi’u cadarnhau yn y ffurfweddiad sy’n rhedeg, gwiriwch fod y ddau westeiwr yn cyflwyno tystysgrifau a gyhoeddwyd ar gyfer yr enwau y maent wedi’u ffurfweddu â hwy a bod y CA yr un fath ar y ddwy ochr. Cadwch ffurfweddiad y tystysgrifau a’r wal dân yn sefydlog wrth i chi newid un gosodiad cludiant ar y tro, oherwydd nid yw golygiad tystysgrif a golygiad relay yn yr un prawf yn dweud dim wrthych pa un ohonynt a symudodd y handshake. Mae anghysondeb enw neu CA yn methu yn yr un man â relay na chafwyd hyd iddo erioed, a dyna pam mae’r gwrth-wiriad hwn yn perthyn i’r un pas.
Yna cadarnhewch fod pob datganiad yn y ffeil y mae’n perthyn iddi:
am_relay: truear y gwesteiwr anfon, a’r gwesteiwr hwnnw’n gyrhaeddadwy trwy UDP o’r ddwy ochr.relays:gan enwi cyfeiriad Nebula’r gwesteiwr hwnnw ar y gyrchfan.use_relays: truear y cymar sy’n cychwyn y cysylltiad.- Rheolau i mewn ar y gyrchfan sy’n dal i ganiatáu’r ffynhonnell wirioneddol ar ôl i’r llwybr newid.