WireGuards handskakning fungerar, tjänsten inte

Handskakningen slutförs, klienten visar en färsk överföringsmätare, och ändå misslyckas en begäran till en tjänst på samma server. Den kombinationen förvirrar folk, eftersom tunneln bevisligen fungerar. Det som inte har bevisats är lokal leverans: paketet nådde värden, och värden måste fortfarande acceptera det på rätt socket och lämna det vidare till en process med rättighet att svara. Gå igenom de tre kontrollpunkterna i ordning.

Stanna vid den första som inte håller, och lägg inte till regler för de andra.

Handskakningen bevisar bara tunneln

WireGuards handskakning etablerar nycklar mellan parter och auktoriserar trafik för de intervall som varje part listade. Den säger ingenting om vilka processer som lyssnar på servern, och ingenting om huruvida värdens brandvägg accepterar paket adresserade till en av dess egna adresser.

Just den sista skillnaden missas oftast: trafik till värden själv är lokalt indata, medan trafik som passerar genom värden till någon annanstans är vidarebefordran. De hanteras av olika brandväggskedjor och olika inställningar. Att kontrollera fel kedja kostar en eftermiddag och ger mätare som ser oskyldiga ut.

Läs lyssnaren och rutten

På klienten, bekräfta att serverns tunneladress routas in i tunneln. På servern, bekräfta att det finns en socket på adressen klienten använder, och att processen bakom är den du avsåg.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

En lyssnare på 127.0.0.1 kommer aldrig att svara på en begäran adresserad till 10.66.0.1, oavsett vad brandväggen tillåter. En lyssnare på jokerteckenadressen gör det, om inte en regel blockerar den. Socketlistan avgör därför hälften av fallen innan någon regel undersöks. Port och adress avgör tillsammans om en begäran kan landa.

Jämför adressen klienten använder med adressen servern faktiskt har på tunnelgränssnittet. En inaktuell konfiguration på endera sidan ger en begäran som routas korrekt till en part som inte har den adressen.

Tillämpa regler för lokalt indata, inte för vidarebefordran

Om paketet anländer och socketen finns är den återstående gränsen indatapolicyn. En regel som tillåter vidarebefordran tillåter inte lokal leverans, och en regel begränsad till ett gränssnitt matchar kanske inte det gränssnittsnamn för tunneln som du förväntar dig.

Testa med en enda tillåten port till den avsedda tjänsten i stället för att öppna värden. Kontrollera sedan applikationens egen auktorisering: en tillåtelselista, ett kontokrav eller en bindning till ett visst värdnamn kan avvisa en begäran som nätverket levererade med framgång.

Behåll certifikatkontrollerna. En oväntad certifikatidentitet är information om vilken värd som svarade, inte ett hinder att kringgå. Att klicka igenom den döljer den enda ledtråd som identifierar fel tjänst.

Skilj namn-, storleks- och identitetsfel

En tjänst som fungerar på adress men misslyckas på namn är ett DNS-problem, och rättelsen hör hemma i resolverkonfigurationen som skickas till klienten, inte i brandväggen. En tjänst som svarar på små begäranden men fastnar på större svar pekar på paketstorlek och MTU, vilket är en helt annan undersökning.

Ett HTTPS-fel som namnger fel värd betyder oftast att begäran nådde en annan tjänst, ofta för att en proxy eller en annan lyssnare äger den porten. Läs certifikatets subjekt och jämför det med värden du ville nå. Den jämförelsen kostar ingenting och avslutar ofta undersökningen.

Anteckna vilken kontrollpunkt som misslyckades: socket, indataregel eller applikationspolicy. Den enda raden skiljer ett nätverksfel från ett behörighetsbeslut. Den hindrar också nästa person från att öppna portar som aldrig var problemet.