WireGuardin kättely toimii, palvelu ei

Kättely valmistuu, asiakas näyttää tuoreen siirtolaskurin, ja silti saman palvelimen palveluun kohdistuva pyyntö epäonnistuu. Yhdistelmä hämmentää, koska tunneli selvästi toimii. Todistamatta on paikallinen toimitus: paketti saapui isäntään, ja isännän on vielä hyväksyttävä se oikeassa pistokkeessa ja annettava se prosessille, jolla on lupa vastata. Käy nämä kolme tarkistuspistettä järjestyksessä läpi.

Pysähdy ensimmäiseen, joka ei pidä, äläkä lisää sääntöjä muille.

Kättely todistaa vain tunnelin

WireGuardin kättely luo avaimet vertaisten välille ja valtuuttaa liikennettä väleille, jotka kukin vertainen luetteli. Se ei kerro mitään siitä, mitkä prosessit kuuntelevat palvelimella, eikä siitä, hyväksyykö isännän palomuuri paketit, jotka on osoitettu johonkin sen omista osoitteista.

Juuri tämä viimeinen ero jää useimmin huomaamatta: liikenne isäntään itseensä on paikallista syötettä, kun taas isännän läpi muualle kulkeva liikenne on edelleenlähetystä. Niitä käsittelevät eri palomuuriketjut ja eri asetukset. Väärän ketjun tarkistaminen maksaa iltapäivän ja palauttaa laskureita, jotka näyttävät viattomilta.

Lue kuuntelija ja reitti

Vahvista asiakkaassa, että palvelimen tunneliosoite reitittyy tunneliin. Vahvista palvelimessa, että asiakkaan käyttämässä osoitteessa on pistoke ja että sen takana oleva prosessi on se, jonka tarkoitit.

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/

Osoitteessa 127.0.0.1 kuunteleva ei koskaan vastaa osoitteeseen 10.66.0.1 osoitettuun pyyntöön, mitä palomuuri sallii. Yleisosoitteessa kuunteleva vastaa, ellei sääntö estä sitä. Pistokeluettelo ratkaisee siis puolet tapauksista ennen kuin yhtäkään sääntöä tutkitaan. Portti ja osoite yhdessä ratkaisevat, voiko pyyntö saapua perille.

Vertaa asiakkaan käyttämää osoitetta osoitteeseen, joka palvelimella todella on tunnelirajapinnassa. Vanhentunut kokoonpano kummalla tahansa puolella tuottaa pyynnön, joka reitittyy oikein vertaiselle, jolla ei ole sitä osoitetta.

Käytä sääntöjä paikalliseen syötteeseen, älä edelleenlähetykseen

Jos paketti saapuu ja pistoke on olemassa, jäljellä oleva raja on syötekäytäntö. Sääntö, joka sallii edelleenlähetyksen, ei salli paikallista toimitusta, eikä yhteen rajapintaan rajattu sääntö välttämättä vastaa odottamaasi tunnelirajapinnan nimeä.

Testaa yhdellä sallitulla portilla aiottuun palveluun sen sijaan että avaisit isännän. Tarkista sitten sovelluksen oma valtuutus: sallittujen luettelo, tiliä koskeva vaatimus tai sitominen tiettyyn isäntänimeen voi hylätä pyynnön, jonka verkko toimitti onnistuneesti.

Pidä varmenteen tarkistukset paikallaan. Odottamaton varmenteen identiteetti on tietoa siitä, mikä isäntä vastasi, ei ohitettava este. Läpi klikkaaminen piilottaa ainoan vihjeen, joka osoittaa väärän palvelun.

Erottele nimen, koon ja identiteetin viat

Palvelu, joka toimii osoitteella mutta epäonnistuu nimellä, on DNS-ongelma, ja korjaus kuuluu asiakkaalle toimitettavaan resolverin kokoonpanoon, ei palomuuriin. Palvelu, joka vastaa pieniin pyyntöihin mutta juuttuu suurempiin vastauksiin, viittaa paketin kokoon ja MTU:hun, mikä on täysin eri tutkimus.

Väärän isännän nimeävä HTTPS-virhe tarkoittaa yleensä, että pyyntö päätyi toiseen palveluun, usein siksi että välityspalvelin tai toinen kuuntelija omistaa sen portin. Lue varmenteen subjekti ja vertaa sitä isäntään, johon halusit päästä. Vertailu ei maksa mitään ja päättää tutkimuksen usein.

Kirjaa, mikä tarkistuspiste petti: pistoke, syötesääntö vai sovelluskäytäntö. Se yksi rivi erottaa verkkovian valtuutuspäätöksestä. Se myös estää seuraavaa henkilöä avaamasta portteja, jotka eivät koskaan olleet ongelma.