WireGuard-handskakningen lyckas, men inget svar kommer tillbaka

Nyliga handskakningar är goda nyheter och ett mycket mindre påstående än meningen folk vill skriva. Parterna utbytte autentiserade handskakningsmeddelanden. Ett applikationspaket måste ändå nå sin inre destination och komma tillbaka.

Klyftan mellan ett friskt kontrollplan och ett tyst dataplan är hela ämnet här. Två avläsningar av samma räknare säger vilken sida av den du står på.

En handskakning bevisar nycklar, inte leverans

WireGuard-handskakningen är en nyckelöverenskommelse med autentisering. Den lyckas så snart parterna kan nå varandra och har giltiga nycklar. Routing, brandmurspolicy och själva destinationen är frågor som handskakningen aldrig ställer.

En tunnel kan alltså vara perfekt upprättad medan varje paket i den kastas. Ett felroutat inre paket och ett svar som tar en annan väg ser likadana ut från klientens sida.

En enda inre adress är hela testet

Välj en destination och håll dig till den. Motpartens egen tunneladress är det enklaste fallet, och en värd bakom motparten lägger till exakt ett hopp. Att växla mellan dem utan att anteckna ändringen ger resultat som ingen kan jämföra.

Titta sedan på den rutt klienten väljer. En mer specifik lokal rutt kan skicka paketet någon annanstans innan WireGuard ens tillfrågas, och det händer varje gång hemmanätet överlappar det avlägsna intervallet.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

En adress som löses upp mot det fysiska gränssnittet har redan svarat på frågan. Tunneln kastar ingenting. Paketet kom aldrig in i den.

Räknare är bevis, inte dom

wg show rapporterar byte skickade och mottagna per part, och de två talen rör sig oberoende av varandra. Ta en avläsning, gör en tillåten begäran och ta sedan en ny avläsning inom samma minut.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Skickande som stiger medan mottagandet står stilla är signaturen för en obesvarad begäran. Det säger inte om begäran filtrerades, om destinationen var nere eller om svaret gick ut en annan väg. Det är tre utredningar med ett symptom. Skilj dem åt innan du ändrar någon konfiguration.

Inte heller ett fast byteantal är en framgångströskel. Räknarvärdena följer trafiken, och att behandla ett enda tal som bevis på hälsa ger självsäkert nonsens.

Motparten granskar själv returpaketet

Den avlägsna parten accepterar bara ett inre paket när källan faller inom dess allowedips. En rutt som finns hos avsändaren räcker inte. En saknad källpost hos mottagaren kastar returtrafiken i tysthet.

Värdens brandmurar står bakom den kontrollen. En vidarebefordringsregel som tillåter tunnelgränssnittet men inte det inre subnätet accepterar handskakningen och avvisar paketet. Från klientsidan ser det ut precis som en död motpart. En värd med två gränssnitt kan också svara från fel källa, och då kastar parten det svar den aldrig väntade sig.

Håll experimentet ärligt

Att testa en fjärråtkomstprofil från samma hemnätverk som den ska nå övar en annan väg än den avsedda. Flytta till det externa nätverket och anteckna dess lokala prefix, så att de två körningarna kan jämföras.

Ett litet lyckat utbyte utesluter inte heller alla vägproblem. Större paket kan misslyckas där små kommer igenom, och ett filter som matchar storlek eller protokoll kan bete sig annorlunda under last.

Behåll handskakningen som det känt fungerande steget och gå vidare därifrån. Nästa användbara bevis är var en inre begäran stannar, inte en ny uppsättning nycklar och ännu en omgång gissningar.