De WireGuard-handshake werkt, de dienst niet

De handshake rondt af, de client toont een recente overdrachtsteller, en toch mislukt een verzoek aan een dienst op dezelfde server. Die combinatie verwart mensen, omdat de tunnel aantoonbaar werkt. Wat niet is aangetoond, is lokale aflevering: het pakket bereikte de host, en de host moet het nog accepteren op de juiste socket en doorgeven aan een proces met toestemming om te antwoorden. Loop die drie controlepunten in volgorde na.

Stop bij het eerste dat niet klopt, en voeg voor de andere geen regels toe.

De handshake bewijst alleen de tunnel

De handshake van WireGuard stelt sleutels in tussen peers en autoriseert verkeer voor de bereiken die elke peer heeft opgesomd. Hij zegt niets over welke processen op de server luisteren, en niets over of de firewall van de host pakketten accepteert die aan een van zijn eigen adressen zijn gericht.

Juist dat laatste onderscheid wordt het vaakst gemist: verkeer naar de host zelf is lokale invoer, terwijl verkeer dat via de host naar elders gaat doorsturen is. Ze worden door verschillende firewallketens en verschillende instellingen afgehandeld. De verkeerde keten controleren kost een middag en levert tellers op die onschuldig lijken.

Lees de luisteraar en de route

Bevestig op de client dat het tunneladres van de server de tunnel in wordt gerouteerd. Bevestig op de server dat er een socket bestaat op het adres dat de client gebruikt, en dat het proces erachter het bedoelde is.

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/

Een luisteraar op 127.0.0.1 zal nooit antwoorden op een verzoek dat aan 10.66.0.1 is gericht, wat de firewall ook toestaat. Een luisteraar op het jokeradres zal dat wel doen, tenzij een regel hem blokkeert. De socketlijst beslecht dus de helft van de gevallen voordat er een regel wordt bekeken. Poort en adres bepalen samen of een verzoek kan aankomen.

Vergelijk het adres dat de client gebruikt met het adres dat de server werkelijk op de tunnelinterface heeft. Een verouderde configuratie aan een van beide kanten levert een verzoek op dat correct wordt gerouteerd naar een peer die dat adres niet heeft.

Pas regels toe voor lokale invoer, niet voor doorsturen

Als het pakket aankomt en de socket bestaat, is de resterende grens het inputbeleid. Een regel die doorsturen toestaat, staat lokale aflevering niet toe, en een regel die tot één interface beperkt is, past mogelijk niet bij de interfacenaam van de tunnel die u verwacht.

Test met één toegestane poort naar de beoogde dienst in plaats van de host te openen. Controleer daarna de eigen autorisatie van de applicatie: een toelatingslijst, een accountvereiste of een binding aan een specifieke hostnaam kan een verzoek weigeren dat het netwerk met succes heeft afgeleverd.

Laat certificaatcontroles staan. Een onverwachte certificaatidentiteit is informatie over welke host heeft geantwoord, geen obstakel om te omzeilen. Erdoorheen klikken verbergt de enige aanwijzing die de verkeerde dienst identificeert.

Scheid naam-, grootte- en identiteitsfouten

Een dienst die op adres werkt maar op naam faalt, is een DNS-probleem, en de oplossing hoort in de resolverconfiguratie die naar de client wordt gestuurd, niet in de firewall. Een dienst die kleine verzoeken beantwoordt maar bij grotere antwoorden vastloopt, wijst op pakketgrootte en MTU, wat een heel ander onderzoek is.

Een HTTPS-fout die de verkeerde host noemt, betekent meestal dat het verzoek een andere dienst heeft bereikt, vaak omdat een proxy of een andere luisteraar die poort bezit. Lees het subject van het certificaat en vergelijk het met de host die u wilde bereiken. Die vergelijking kost niets en beëindigt het onderzoek vaak.

Noteer welk controlepunt faalde: socket, inputregel of applicatiebeleid. Die ene regel onderscheidt een netwerkstoring van een autorisatiebeslissing. Het voorkomt ook dat de volgende persoon poorten opent die nooit het probleem waren.