WireGuard 5G sangay: hayaang ang sangay ang tumawag sa hub

Ang ituro ang isang sangay sa isang hub ay ang madaling kalahati ng disenyong ito kapag ang sangay ay nasa likod ng nagbabagong mobile address at ang hub ay may matatag na pangalan. Pagkatapos, natututuhan ng hub ang sangay mula sa authenticated na trapiko, sa halip na mula sa talaan na kailangan mong panatilihing napapanahon. Simple ang kasunduan: ang sangay ang laging nagsisimula.

I-configure ito nang sadya, pagkatapos ay i-verify ang bahaging inaakalang gumagana. Ang dalawang hakbang ay tumatagal ng minuto, at sa pangalawa karaniwang nabibigo ang mga disenyong ito.

Aling panig ang may matatag na endpoint

Binabanggit ng configuration ng sangay ang endpoint at public key ng hub. Binabanggit ng configuration ng hub ang public key ng sangay at ang mga pinapayagang panloob na prefix nito, at maaaring wala itong anumang endpoint, dahil ang pagkakakilanlan ay nagmumula sa key at hindi sa source address ng huling packet. Ang kawalan ng simetriya na iyon ang buong mekanismo, at inaalis nito ang isang buong klase ng problema sa pagtuklas mula sa panig ng hub.

Kapag nagpadala ang sangay ng authenticated na packet, itinatala ng hub ang pinagmulan nito at ginagamit ang mapping na iyon para sa mga tugon. Ang muling pagbilang ng mobile link ay wala nang gastos maliban sa susunod na handshake, at bawat component na hindi mo na kailangan ay isa na hindi maaaring mabigo sa panahon ng paglipat. Sulit subukan ang katangiang iyon sa isang nakaplanong pagbabago at hindi sa panahon ng insidente. Gawin ito habang may makakatingin sa dalawang dulo nang sabay.

Bigyan ang sangay ng configuration na nakakaligtas sa muling pagbilang

Panatilihin ang endpoint at keepalive sa sangay, at panatilihing walang hard-coded na address ang peer entry sa hub. Pinapanatili ng keepalive na bukas ang isinalin na mapping nang sapat na katagalan upang makapagpadala ang hub ng hindi hinihiling na trapiko pagkatapos ng panahong walang aktibidad.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Dalawampu’t limang segundo ang madalas na binabanggit na halimbawa para panatilihing buhay ang NAT mapping, hindi isang kahilingan para sa bawat peer. Itakda ito ayon sa timeout ng mapping na talagang nakikita mo, at tandaan na gumagawa ito ng trapiko sa link na may limitasyon sa data habang nakabukas ang interface.

Sa hub, dapat saklawin ng mga pinapayagang prefix ng peer ng sangay ang lahat ng ipapadala ng sangay. Ang nawawalang prefix kumikilos na parang pagkabigo sa routing sa malayong dulo at walang nagagawang babala sa alinmang panig, kaya sulit itong suriin bago ang unang tunay na packet. Ihambing ang mga pinapayagang prefix ng hub sa mga interface address ng sangay bago ang unang koneksyon.

I-verify ang mapping at ang failover

Kumpirmahin na natatapos ang handshake, na inililista ng hub ang kasalukuyang endpoint ng sangay, at na naaabot ang mga panloob na address ng sangay sa pamamagitan ng tunnel. Iyon ang baseline, at dapat itong itala bago may humawak sa mobile link. Sapat na ang dalawang linya ng output. Itago ang mga ito sa ticket kasama ang timestamp.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Pagkatapos, subukan ang pagkabigo kung saan umiiral ang disenyong ito. Hilahin ang pangunahing WAN at kumpirmahin na ang pinagbabatayang ruta ng sangay patungo sa hub ay lumalabas na ngayon sa pamamagitan ng mobile interface. Hindi kayang ayusin ng tunnel ang sirang pisikal na landas, kaya ang panlabas na ruta na patuloy na tumuturo sa patay na uplink ay gumagawa ng timeout ng handshake na mukhang eksaktong problema ng hub.

Kung ang panlabas na landas ay tahasang nakatali o naka-route ayon sa patakaran, dapat itong isama sa failover. Ang agwat na iyon sa pagitan ng disenyong tamang binabasa at ng isang nakakaligtas sa pagkaantala ang karaniwang tanging kulang.

Ano ang hindi nilulutas ng disenyong ito

Wala rito ang pumapayag ng papasok na koneksyon sa sangay. Kung may kailangang tumawag sa mobile site sa punong tanggapan, mali ang direksyon ng tunnel para sa pangangailangang iyon, at ang dynamic na DNS ay nag-a-update lamang ng pangalan. Ang pagsasalin ng provider, patakaran sa papasok at pag-refresh ng endpoint ng kliyente ay nananatiling nakaharang, at ang binagong record ay hindi makakabukas ng carrier-grade NAT.

Panatilihing naiiba ang prefix ng sangay sa bawat ibang site, at limitahan ang ipapasa ng gateway nito. Pinapasimple ng matatag na hub endpoint ang pagtuklas at wala itong ginagawa para sa routing design, pagpaplano ng address o sa tanong kung aling mga application route ang nakakaligtas sa failover.

Isulat ang apat na bagay sa runbook: sino ang nagsisimula, aling mga prefix ang pinapayagan, gaano katagal ang keepalive, at ano ang nangyayari kapag bumagsak ang pangunahing link. Ang mga linyang iyon ang talagang kailangan ng susunod na operator sa alas-tres ng madaling-araw.