WireGuard-handskud werk, die diens nie

Die handskud voltooi, die kliënt wys 'n onlangse oordragteller, en 'n versoek na 'n diens op dieselfde bediener misluk steeds. Dié kombinasie verwar mense, want die tonnel werk duidelik. Wat nie bewys is nie, is plaaslike aflewering: die pakket het die gasheer bereik, en die gasheer moet dit steeds op die regte sokkel aanvaar en aan 'n proses met toestemming om te antwoord oorhandig. Werk daardie drie kontrolepunte in volgorde deur.

Stop by die eerste een wat nie hou nie, en moenie reëls vir die ander byvoeg nie.

Die handskud bewys net die tonnel

WireGuard se handskud vestig sleutels tussen eweknieë en magtig verkeer vir die reekse wat elke eweknie gelys het. Dit sê niks oor watter prosesse op die bediener luister nie, en niks oor of die gasheer se vuurmuur pakkette aanvaar wat aan een van sy eie adresse gerig is nie.

Daardie laaste onderskeid word die meeste gemis: verkeer na die gasheer self is plaaslike invoer, terwyl verkeer wat deur die gasheer na elders beweeg deurvoer is. Hulle word deur verskillende vuurmuurkettings en deur verskillende instellings hanteer. Om die verkeerde ketting na te gaan mors 'n middag en gee tellers wat onskuldig lyk.

Lees die luisteraar en die roete

Op die kliënt, bevestig dat die bediener se tonneladres in die tonnel inroeteer. Op die bediener, bevestig dat 'n sokkel bestaan op die adres wat die kliënt gebruik, en dat die proses daarby die een is wat jy bedoel het.

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/

'n Luisteraar op 127.0.0.1 sal nooit 'n versoek antwoord wat aan 10.66.0.1 gerig is nie, maak nie saak wat die vuurmuur toelaat nie. 'n Luisteraar op die wildkaartadres sal dit wel doen, tensy 'n reël dit blokkeer. Die sokkelinskrywing beslis dus die helfte van die gevalle voordat enige reël ondersoek word. Poort en adres saam besluit of 'n versoek kan land.

Vergelyk die adres wat die kliënt gebruik met die adres wat die bediener werklik op die tonnelkoppelvlak besit. 'n Verouderde konfigurasie aan enige kant lewer 'n versoek wat korrek na 'n eweknie geroteer word wat nie so 'n adres het nie.

Pas reëls toe vir plaaslike invoer, nie deurvoer nie

As die pakket aankom en die sokkel bestaan, is die oorblywende grens die invoerbeleid. 'n Reël wat deurvoer toelaat, laat nie plaaslike aflewering toe nie, en 'n reël wat op een koppelvlak gemik is, pas dalk nie by die tonnelkoppelvlaknaam wat jy verwag nie.

Toets met 'n enkele toegelate poort na die beoogde diens eerder as om die gasheer oop te maak. Kontroleer dan die toepassing se eie magtiging: 'n toelaatlys, 'n rekeningvereiste of 'n binding aan 'n spesifieke gasheernaam kan 'n versoek verwerp wat die netwerk suksesvol afgelewer het.

Hou sertifikaatkontroles in plek. 'n Onverwagte sertifikaatidentiteit is inligting oor watter gasheer geantwoord het, nie 'n hindernis om te omseil nie. Om daaroor te klik verberg die een leidraad wat die verkeerde diens identifiseer.

Skei naam-, grootte- en identiteitsfoute

'n Diens wat per adres werk maar per naam misluk, is 'n DNS-probleem, en die regstelling hoort in die opsoekkonfigurasie wat aan die kliënt gestuur word, nie in die vuurmuur nie. 'n Diens wat klein versoeke antwoord maar op groter antwoorde vasval, dui op pakketgrootte en MTU, wat 'n heeltemal ander ondersoek is.

'n HTTPS-fout wat die verkeerde gasheer noem, beteken gewoonlik dat die versoek 'n ander diens bereik het, dikwels omdat 'n gevolmagtigde of 'n ander luisteraar daardie poort besit. Lees die sertifikaat se onderwerp en vergelyk dit met die gasheer wat jy wou bereik. Daardie vergelyking kos niks en beëindig dikwels die ondersoek.

Teken aan watter kontrolepunt misluk het: sokkel, invoerreël of toepassingsbeleid. Daardie enkele reël onderskei 'n netwerkfout van 'n magtigingsbesluit. Dit verhoed ook dat die volgende persoon poorte oopmaak wat nooit die probleem was nie.