Gumagana lang ang WireGuard pagkatapos magpadala ng server: kaalaman sa endpoint

Mukhang gumagana lang ang tunnel pagkatapos magpadala muna ng isang bagay ang server. Simulan mula sa client at walang nangyayari, maghintay ng ilang segundo, subukan muli at nagtagumpay ito. Ang karaniwang diagnosis ay sirang NAT, at ang karaniwang diagnosis ay mali. Ang nagbago ay natutunan ng isang peer kung saan nakatira ang isa.

Kaalaman sa endpoint, hindi kakayahang maabot

Hindi magsisimula ng handshake ang isang peer ng WireGuard hangga't hindi nito alam kung saan ito ipapadala. Ibinibigay ito ng configuration bilang endpoint ng address at port, at sinusundan ng tumatakbong estado ang endpoint na pinaniniwalaan nito ngayon.

wg show naglilimbag ng dalawang panig ng larawang iyon, at ang isang peer na walang endpoint sa output ay hindi makapagsimula ng anuman, gaano man katumpak ang pampublikong key at mga pinapayagang prefix nito. Ihambing ang pananaw ng client sa pananaw ng server bago baguhin ang anumang tuntunin, dahil madalas silang hindi magkasundo kung sino ang nakakaalam ng ano.

Paano natututo ang isang peer ng endpoint

Sadyang tahimik ang WireGuard. Kapag may tamang na-authenticate na packet na dumating mula sa address na hindi inaasahan ng peer, ina-update ng implementasyon ang endpoint ng peer na iyon sa bagong pinagmulan, at ganoon gumagana ang roaming sa isang laptop na nagpapalit ng network. Ipinapaliwanag ng gawi na iyon ang pagdepende sa direksyon: kung ang server ang unang magpadala at umabot ang packet nito sa client, natututunan ng client ang kasalukuyang address ng server at makakasagot ito. Hanggang doon ay wala itong mapagpadalhan. Ang mekanismo ay authenticated roaming at hindi isang shortcut ng tiwala sa unang paggamit, dahil kailangang maging wasto ang packet bago gumalaw ang endpoint.

Inilalarawan ng dokumentasyon ng mga tool para sa wg ang update na iyon, at sulit itong basahin minsan kung magdidisenyo ka sa paligid nito.

Nagdaragdag ng sariling direksyon ang pagsasaling may estado

Kung saan dumadaan ang UDP sa isang gateway na nagsasalin, gumagawa ang gateway ng estado para sa unang packet na nakikita nito. Inilalarawan ng RFC 4787 ang gawi na iyon at ang mga timeout na kalaunan ay nag-aalis ng mapping. Nag-expire ang isang idle na mapping, at ang isang papasok na packet mula sa malayong panig ay itinatapon ng gateway bago pa ito umabot sa host. Ang isang tunnel na gumana buong umaga ay humihinto sa pagsagot sa hapon dahil mismo sa kadahilanang ito.

Ito ay pangalawa at malayang mekanismo na gumagawa ng parehong sintomas ng direksyon. Parehong dapat tama ang kaalaman sa endpoint at estado ng pagsasalin, at ang pag-aayos ng isa ay hindi nag-aayos ng isa.

I-configure ang direksyong talagang gusto mo

Para sa isang client na dapat magsimula ng koneksyon, ilagay ang endpoint ng server sa seksyon ng mga peer ng client at hayaang manatili doon. Ang umasa na ang server ang unang magpadala ay umasa sa isang pagkakataon sa pagkakasunod-sunod ng trapiko na magbabago sa isang tahimik na network. Dapat ipahayag ng configuration ang nilalayong direksyon, hindi ito tuklasin.

Para sa isang peer sa likod ng pagsasalin na dapat manatiling maabot, paganahin ang isang patuloy na keepalive sa panig na iyon. Ang keepalive tuwing 25 segundo ay ang karaniwang panimulang halaga, at ang layunin nito ay panatilihing bukas ang mapping sa halip na subukan ang tunnel. Pumili ng isang panig na magdadala nito, dahil ang pagpapagana sa dalawang panig ay nagdodoble ng trapiko at ingay ng log nang hindi pinapabuti ang resulta.

Ihambing ang estado bago at pagkatapos ng trigger

Kunin ang dalawang pananaw sa sandaling mabigo ito, pagkatapos muli pagkatapos magpadala ang server. Ipinapakita ng unang utos ang mga endpoint at edad ng handshake. Ipinapakita ng pangalawa kung may entry ng pagsasalin para sa port. Ipinapakita ng pagkuha kung aling direksyon ang talagang tumawid sa kable, at kinukumpirma ng pagsusuri ng ruta na hindi ipinapadala ng client ang trapikong iyon sa ibang lugar nang lubusan.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Itala ang column ng endpoint at ang entry ng pagsasalin nang magkasama. Ang peer na walang endpoint at gateway na walang mapping ay dalawang magkaibang depekto. Isa lamang sa kanila ang naaayos ng keepalive.