Buong tunnel ng WireGuard: AllowedIPs 0.0.0.0/0 ay hindi sapat

Ang paglalagay ng 0.0.0.0/0, ::/0 sa AllowedIPs ng isang peer ay ang hakbang na natatandaan ng lahat, at pinagpapasyahan lamang nito kung aling trapiko ang pinapayagang dalhin ng peer. Hindi gumagawa ng ruta ang mga prefix na ito, walang ipinapasa sa kabilang panig, at iniiwan ang resolver ng bawat aplikasyon kung nasaan ito. Apat na magkakahiwalay na bagay ang dapat totoo nang sabay para maging buong tunnel ang isang buong tunnel, at pinakamainam silang suriin sa pagkakasunod-sunod sa ibaba, dahil hindi kayang iligtas ng huling pagsusuri ang nauna. Bawat pagsusuri sa ibaba ay katotohanang mababasa mula sa makina, hindi setting na inaasahan mong nailapat.

Ano ang pinipili ng prefix ng peer, at ano ang hindi

Ang AllowedIPs ay parehong tagapili at pahintulot. Sinasabi nito sa lokal na panig kung aling destinasyon ang maaaring ipadala sa peer na ito, at sinasabi sa tumatanggap na panig kung aling source address ang maaaring ipakita ng peer na ito. Iyon ang buong gawain. Wala sa paglalarawang iyon ang gumagawa ng ruta sa host, nagbubukas ng pagpapasa sa malayong panig, o humahawak sa resolusyon ng pangalan.

Kaya naman ang isang configuration ay maaaring magmukhang kumpleto at kumilos na parang split tunnel. Sinasabi ng prefix na tatanggapin ng peer ang lahat; ang routing table ng host ang nagpapasya kung ano ang tunay na dumarating doon, at ang gateway ang nagpapasya kung may lumalabas. Wala sa tatlong desisyong iyon ang nakatira sa seksyon ng peer.

Rutahan ang kliyente, hindi lang ang listahan ng peer

Ang mga tagapamahala tulad ng wg-quick ay nagpoprograma ng routing table ng host para sa iyo, kaya naman magkaiba ang kilos ng dalawang magkatulad na configuration file depende sa kung paano umangat ang interface. Ang pinakamaliit na profile ay sapat na maikli para basahin sa isang buga:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Dalawang detalye ang nagdadala ng gawain. Ang field na Address ay isang solong host prefix at hindi subnet na inaakalang pag-aari ng kliyente, at ang tagapamahala ang nagpapalit ng default na AllowedIPs sa tunay na default na ruta. Iangat ang parehong file gamit ang ip link at wg setconf at wala talagang lalabas na ruta, na mukhang sirang tunnel ngunit sa totoo ay malusog na tunnel na nilaktawan ang hakbang sa routing. Ang manwal ng wg-quick ay nagdodokumento ng routing at ng Table pag-uugaling idinadagdag ng mga tagapamahalang iyon.

Basahin ang resulta hindi ang file: ip route get 1.1.1.1 dapat pangalanan ang interface ng tunnel, at wg show dapat mag-ulat ng kamakailang handshake na may gumagalaw na transfer counter. Ang handshake na walang ruta ay nangangahulugang hindi kailanman tumakbo ang tagapamahala, at hindi ito maaayos ng muling pag-edit ng profile. Simulan ang interface gaya ng gagawin ng gumagamit, kung hindi ay sinusukat ng test ang shell mo sa halip na ang deployment.

Panatilihin ang endpoint sa labas ng tunnel

Kinukuha ng buong tunnel ang bawat destinasyon, kasama ang kailangang kausapin para umiral. Hinaharap ito ng mga tagapamahala sa pamamagitan ng pagdaragdag ng host route para sa endpoint sa orihinal na gateway, kaya naman halos palaging may isang sadyang pagbubukod ang tamang configuration. Ang paglalapat ng kalahati ng configuration gamit ang tagapamahala at ng kalahati sa kamay ang karaniwang paraan ng pagkawala ng pagbubukod na ito.

Kung ang endpoint ay isang hostname na nagre-resolve sa maraming address, o sa pamilyang hindi mo dinadala, masamang tumatanda ang pagbubukod at maaaring mabigo ang tunnel pagkatapos ng muling pagkonekta na mukhang karaniwan. I-pin ang endpoint sa address na kontrolado mo, o tiyakin na muling sinusuri ito ng tagapamahala, at muling basahin ang host route pagkatapos ng bawat pagbabago sa network.

Nagpapaliwanag ang parehong mekanismo kung bakit nag-aaway ang buong tunnel at captive portal. Inaasahan ng portal na harangin ang trapikong kinukuha na ng tunnel mo, kaya sa mga network ng hotel at paliparan, iniaangat mo ang tunnel pagkatapos ng pag-login sa portal, hindi kailanman bago iyon.

Pagpapasa at daan pabalik sa gateway

Sa gateway, buksan ang pagpapasa para sa pamilyang dinadala mo, payagan ang forward chain sa dalawang direksyon kapag nag-translate ka, at tiyakin ang daan pabalik sa pamamagitan ng paghahanap na tiyak sa pinagmulan. Wala sa mga ito ang nagmumula sa matagumpay na handshake, dahil ang handshake ay nagpapatunay lamang na makapagpapalitan ng UDP ang dalawang peer. Wala itong sinasabi tungkol sa mangyayari sa decapsulated packet pagkatapos.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Sa gateway nagpapatakbo ang paghahanap at hindi sa kliyente, kung hindi ay ibang routing table ang babasahin mo. Kung pinangalanan nito ang maling interface, o nag-ulat na walang ruta, walang pagbabago sa panig ng kliyente ang gagawa ng labasan sa internet. Kapag nag-translate ang gateway ng address ng mga kliyente sa paglabas, nakadepende ang sagot sa estado ng translation na iyon, kaya dapat may patakaran para sa dalawang direksyon ng agos at hindi lamang sa palabas.

DNS at ang estado ng pagpalya, sinuri nang hiwalay

Ang protocol mismo ay hindi nagko-configure ng resolver ng anumang aplikasyon. wg-quick inilalapat ang linyang DNS sa pamamagitan ng integrasyon ng resolver ng distribusyon, maaaring balewalain ito ng mga container at browser na may sariling stack, at kaya naman maaaring mabigo ang pangalan habang perpektong nagdadala ng packet ang tunnel. Subukan gamit ang hostname sa halip na address, at itala kung aling server ang sumagot sa halip na ipagpalagay na iyon ang nasa profile.

Ang mga pamilya ng address ay hiwalay na test na may hiwalay na sagot. Walang sinasabi ang default na ruta ng v4 tungkol sa gagawin ng v6 na koneksyon ng isang aplikasyon, at ang tunnel na tahimik na naglalagas ng ikalawang pamilya ay mas masahol pa sa isang malakas na nabigo. Magtanong ng pangalan sa bawat pamilya, basahin ang interface na ginamit ng bawat kahilingan, at suriin ang mga translation counter bago at pagkatapos, dahil ang patakarang walang tinutugma ay mukhang kapareho ng nawawalang patakaran.

Sa huli, subukan ang estadong gusto mo kapag huminto ang tunnel. Dapat mabigo nang sarado ang buong tunnel para sa trapikong inaangkin nito: kung bumagsak ang interface at tahimik na nagpapatuloy ang mga aplikasyon sa pisikal na link, ang disenyo ay split tunnel na may dagdag na hakbang. Isulat ang inaasahang pag-uugali sa pagpalya, suriin ito nang sadya, at tapusin sa pagtatala ng apat na sagot — aling tagapamahala ang nag-aangat ng interface, aling ruta ang nagdadala ng default, sino ang nagpapasa at nag-translate sa gateway, at aling resolver ang sumasagot.