Peer WireGuard yn anghyraeddadwy tra mae un arall yn gweithio: rhestr wirio

Mae un peer WireGuard yn pasio traffig ac mae ail un yn cwblhau’r ysgwyd llaw ond byth yn cyrraedd unrhyw beth y tu ôl i’r tiwnel. Mae’r peer sy’n gweithio yn dweud wrthych fod y rhyngwyneb, y porth UDP a allwedd y gweinydd yn ôl pob tebyg yn iawn. Nid yw’n dweud dim am AllowedIPs yr ail peer, ei gyfeiriad ffynhonnell mewnol na’r rheolau anfon ymlaen rhyngddynt. Ewch drwy’r rhestr yn ei threfn a stopiwch yn y cam cyntaf y mae ei amod yn methu.

Cam 1: Ysgrifennwch y llwybr y dylai’r pecyn ei ddilyn

Nid yw dau gleient ar yr un canolbwynt yn cyrraedd ei gilydd yn awtomatig. Mewn cynllun canolbwynt a phelydrau, mae’r gweinydd yn derbyn y pecyn ar wg0 ac yn gorfod ei anfon yn ôl allan o wg0 at y peer arall, sy’n gofyn am anfon ymlaen IP a rheol anfon ymlaen. Mewn cynllun peer-i-peer uniongyrchol, mae angen pen draw’r llall ar bob ochr a chyfeiriad ei diwnel o fewn AllowedIPs. Penderfynwch pa gynllun yr ydych yn ei ddatfygio cyn darllen unrhyw ffurfweddiad.

Mae’r llwybr disgwyliedig hefyd yn dweud wrthych ble i edrych. Os dylai’r pecyn groesi’r canolbwynt, y naid sy’n methu yw naill ai AllowedIPs yr anfonwr, anfon ymlaen y canolbwynt, neu AllowedIPs y derbynnydd. Os dylai fynd yn uniongyrchol, mae’r canolbwynt yn amherthnasol a chaeau pen draw’r ddau peer sy’n cyfrif.

Cam 2: Cymharwch AllowedIPs ar y ddwy ochr, nid un yn unig

Mae WireGuard yn defnyddio AllowedIPs fel tabl llwybro ac fel rhestr fynediad ar yr un pryd. Wrth anfon, chwiliwyd y cyfeiriad cyrchfan yn AllowedIPs y peer i ddewis y tiwnel; wrth dderbyn, rhaid i’r cyfeiriad ffynhonnell mewnol syrthio o fewn AllowedIPs y peer sy’n anfon neu bydd y pecyn yn cael ei ollwng. Mae ystod ar goll ar un ochr neu’r llall yn cynhyrchu’r un symptom: mae’r cludiant yn gweithio, mae’r llwyth yn diflannu.

Darllenwch y cyflwr byw yn hytrach na’r ffeil, oherwydd efallai fod ail-lwytho wedi methu’n dawel: sudo wg show wg0 allowed-ips. Ar y gweinydd, rhaid i gofnod y peer sy’n methu gynnwys cyfeiriad ei diwnel, er enghraifft 10.90.0.3/32. Ar y cleient, rhaid i gofnod peer y gweinydd gynnwys y cyrchfan yr ydych yn ei phrofi, boed yn gyfeiriad tiwnel y canolbwynt neu’n is-rwydwaith bell. Mae ystodau sy’n gorgyffwrdd yn gwneud y chwiliad yn amwys ac yn gallu dewis peer na fwriedid, felly cadwch hwy ar wahân.

Cam 3: Gwiriwch y cyfeiriad ffynhonnell mewnol

Bydd cleient sy’n llwybro 10.90.0.3 drwy wg0 ond yn anfon pecynnau o’i gyfeiriad Wi-Fi yn cael ei wrthod gan y derbynnydd, oherwydd nad yw’r ffynhonnell yn cyfateb i AllowedIPs y peer. Cadarnhewch yr hyn y mae’r cnewyllyn yn ei ddewis mewn gwirionedd gyda ip route get 10.90.0.3 from 10.90.0.2, a chadarnhewch y cyfeiriad a neilltuwyd i ryngwyneb y tiwnel gyda ip -brief addr show wg0.

Ar y gwesteiwr Linux sy’n derbyn, mae hidlo llwybr cefn yn ail borth. Gall rp_filter llym ar y rhyngwyneb sy’n berchen ar y llwybr yn ôl ollwng traffig tiwnel nad yw ei lwybr dychwelyd yn cyfateb i’r rhyngwyneb y cyrhaeddodd arno. Gwiriwch y gwerth effeithiol cyn ei anablu; mewn llawer o dopolegau’r atgyweiriad cywir yw llwybr, nid hidlydd llacach.

Cam 4: Adolygwch anfon ymlaen y canolbwynt a’r llwybr dychwelyd

Os oes rhaid i’r canolbwynt anfon ymlaen rhwng peerau, mae angen net.ipv4.ip_forward=1 ar y cnewyllyn, a rhaid i’r wal dân dderbyn y llif a anfonir ymlaen: i mewn ar wg0, allan ar wg0, o gyfeiriad tiwnel yr anfonwr i un y derbynnydd. Methiant cyffredin yw rheol fewnbwn sy’n derbyn UDP 51820 ond heb reol anfon ymlaen], felly mae’r ysgwyd llaw yn llwyddo ac mae’r llwyth yn marw. Rhestrwch y rheolau effeithiol gyda sudo nft list ruleset neu’r cyfwerth ar gyfer eich rheolwr wal dân.

Yna gwiriwch yr ateb. Rhaid i’r gwesteiwr cyrchfan fod â llwybr yn ôl at yr anfonwr, naill ai drwy’r canolbwynt neu drwy ei borth ei hun. Os yw’r canolbwynt hefyd yn NATio is-rwydwaith y tiwnel, cadarnhewch fod y cyfieithiad yn berthnasol i’r llif a anfonir ymlaen a bod yr ateb yn cyrraedd y canolbwynt cyn i’r cyflwr ddod i ben. Mae methiant unffordd sy’n edrych fel problem allwedd yn aml yn ddim ond y llwybr dychwelyd hwn.

Yn olaf, gwahanwch yr ysgwyd llaw oddi wrth y data. Mae peer sy’n cwblhau’r ysgwyd llaw ond yn mynd yn sownd ar drawsgludiadau mawr fel arfer yn cael problem MTU neu MSS ar y llwybr penodol hwnnw, nid problem AllowedIPs. Profwch gyda phing bach yn gyntaf, yna un maint llawn, a chymharwch y ddau peer.

Cam 5: Newidiwch un peth a chadwch y peer sy’n gweithio’n gyfan

Gwnewch un newid i’r llwybr sy’n methu ac ailbrofwch y ddau peer. Ailosod AllowedIPs pob peer gyda 0.0.0.0/0 yw’r ffordd gyflymaf i dorri’r peer a oedd eisoes yn gweithio, oherwydd mae’n newid y penderfyniad llwybro ar gyfer yr holl draffig ar y rhyngwyneb hwnnw. Golygwch y cofnod hwnnw, ail-lwythwch, a darllenwch y cyflwr byw yn ôl.

Cofnodwch pa lwybr a lwyddodd, pa un a fethodd, a’r allbwn gorchymyn union ar gyfer pob un. Mae’r gymhariaeth honno’n werth mwy na datganiad cyffredinol fod y VPN wedi torri, a hwn yw’r peth cyntaf y bydd y person nesaf yn gofyn amdano.