WireGuard-hostprefiks: wêrom't ien adres wurket en de rest net

De tunnel is omheech, de handshake bart elke twa minuten, en presys ien adres oan 'e oare kant antwurdet. Pings nei it tunneladres fan 'e peer wurkje; neat dêrfoar. Ien lêst de ynterfacekonfiguraasje, sjocht in hostprefiks en konkludearret dat it masker ferkeard is. It ferbreedzjen nei in /24 reparearret de ping in skoftke en brekt dan wat oars. It prefiks wie nea de skuld, en de rûte dy't ûntbriek is net dejinge dy't it masker betsjinnet.

Wat it ynterfaceprefiks eins skept

Op Linux skept it tawizen fan in adres oan in ynterface in ferbûne rûte foar dat prefiks. Wys do in hostprefiks ta, dan dekt de ferbûne rûte ien adres. Wys do in /24 ta, dan dekt dy 256, en elk dêrfan jildt no as berikber oer dy link.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

In hostprefiks is foar in punt-tot-punt-tunnel in folslein normale kar, want der is presys ien peer oan 'e oare kant. It tredde kommando is dejinge dy't de fraach fan 'e brûker beantwurdet: it seit hokker ynterface de kernel foar dat doel brûke soe, en it lit neat nuttich sjen as der gjin rûte past.

Dat is de hiele ferklearring foar it symptoom. Ien adres antwurdet om't der in ferbûne rûte foar bestiet, of om't de tastiene list fan 'e peer it tafallich befettet. Foar al it oare is der gjin rûte en wurdt it weilitten foardat WireGuard der by belutsen is. De tunnel is al dy tiid sûn, en dêrom sjocht de handshakketeller der noch altyd fertrouwenwekjend út.

AllowedIPs binne twa regels ûnder ien namme

De tastiene list per peer fan WireGuard docht twa taken tagelyk, en de konfiguraasjesyntaksis lit se as ien lykje. Ynkommend bepaalt dy hokker boarneadressen in peer presintearje mei. Utgeand kiest dy nei hokker peer in pakket giet, troch de meast spesifike oerienkomst te sykjen.

Gjin fan beide taken is routing. De kernel moat noch altyd beslute dat in pakket op 'e tunnelinterface heart, foardat WireGuard dernei sjocht, en dy beslissing komt út 'e routingtabel. In peer-ynskriuwing mei in brede tastiene list ynstallearret net fansels in rûte.

Dêrom kin in konfiguraasje folslein lykje en him asymmetrysk gedrage. De kliïnt stjoert nei de oare kant om't der in rûte bestiet, en antwurden komme nea oan om't de tastiene list fan 'e oare kant de boarne fan 'e kliïnt net tastiet, of om't de oare kant gjin werompaad hat. Beide rjochtings binne aparte beslissingen mei aparte flaterwizen. Opskriuwe hokker oftst testest is de helte fan 'e diagnoaze.

Wêr't de rûte wei komt

As do wg-quick brûkst, wurde de rûtes foar dy generearre út 'e tastiene list fan elke peer, of do moatst Table = off setten hawwe en it behear sels oernommen hawwe. Dat is it gedrach dat it helpmiddel dokumintearret, en it is de reden dat in konfiguraasje sûnder eksplisite rûte-ynstruksjes dochs wurket.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Fergelykje de tastiene list mei de rûtes dy't der echt binne. In peer dy't in hiel subnet tastiet mar allinnich in hostrûte opsmiten hat, betsjut dat de helper nea rûn hat, of datst de ynterface direkt mei wg en ip behearst; dan generearret neat rûtes foar dy.

As do it mei de hân behearst, is de rûte ien rigel en syn foarm eksplisyt: it doel troch de ynterface, sûnder gateway om't de link punt-tot-punt is. It tafoegjen is gjin needoplossing foar in min prefiks; it is de ûntbrekkende helte fan in ûntwerp dat routing bewust sels beheart.

In breder prefiks foeget de peer-ynskriuwing net ta

De ferliedlike oplossing is it adres nei in /24 te feroarjen sadat de ferbûne rûte it LAN fan 'e tsjinner dekt. It liket te wurkjen, en de reden dat it liket te wurkjen is dat de ferbûne rûte no past, net dat WireGuard wat nijs leard hat.

Watst ek dien hast, is it hiele berik as direkt berikber oer dy link opeaskje, ynklusyf adressen dy't by oare peers of by in LAN efter de tsjinner hearre. Ferkiers nei dy adressen komt no de tunnel yn, en oft it der oan 'e oare kant wer út komt hinget ôf fan 'e routing en tastiene listen fan 'e tsjinner.

De kryptokant bliuwt hoe dan ek ûnoantaaste. WireGuard hat noch altyd in ynskriuwing yn 'e tastiene list nedich dy't it doel dekt om in peer te kiezen, en de oare kant hat noch altyd in ynskriuwing nedich dy't dyn boarne dekt om dy te akseptearjen. In breder ynterfaceprefiks kin gjin fan beide leverje.

Befêstigje beide rjochtings foardatst wat feroarjest

Wurkje de beide einen apart ôf en skriuw op wat elk seit. Op 'e kliïnt de rûte en de peer-ynskriuwing; op 'e tsjinner it spegelbyld plus syn eigen werompaad:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

De opname is wat skeel oer rjochting beslissend is. As útgeande pakketten op 'e tunnelinterface ferskine en de tsjinner logt neat, dan ferwurdt de oare kant se, meastentiids om't dyn boarne bûten syn tastiene list falt. As der hielendal neat ferskynt, ûntbrekt de rûte of wiist dy earne oars hinne.

Reparearje dan de smelste ein. In ynskriuwing yn 'e tastiene list oan tsjinnerkant foar dyn kliïntadres en in ynskriuwing oan kliïntkant foar it doelsubnet is de normale foarm, en dy lit it ynterfaceprefiks gewurde. Ferbreedzje it prefiks allinnich as it adresplan echt in dield subnet op dy link wol, en doch it as in planferoaring ynstee fan in debugstap.