De WireGuard-hânjaan wurket, de tsjinst net

De hânjaan makket klear, de klant lit in resinte oerdrachtsteller sjen, en dochs mislearret in fersyk nei in tsjinst op deselde tsjinner. Dy kombinaasje ferbjusteret minsken, om't de tunnel oantoanber wurket. Wat net bewiisd is, is pleatslike levering: it pakket hat de host berikt, en de host moat it noch op 'e juste socket akseptearje en trochjaan oan in proses mei tastimming om te antwurdzjen. Wurkgje dy trije kontrôlepunten op folchoarder ôf.

Stop by it earste dat net stiet, en foegje foar de oaren gjin regels ta.

De hânjaan bewiist allinnich de tunnel

De hânjaan fan WireGuard set kaaien op tusken pearen en autorisearret ferkear foar de berikken dy't elk pear neamd hat. It seit neat oer hokker prosessen op 'e tsjinner harkje, en neat oer oft de firewall fan 'e host pakketten akseptearret dy't nei ien fan syn eigen adressen stjoerd binne.

Krekt dat lêste ûnderskie wurdt it meast mist: ferkear nei de host sels is pleatslike ynfier, wylst ferkear dat troch de host nei earne oars giet trochstjoering is. Se wurde troch ferskate firewallkeatlingen en ferskate ynstellings hanthanne. De ferkearde keatling kontrolearje kostet in middei en jout tellers werom dy't ûnskuldich lykje.

Lês de harker en de rûte

Befêstigje op 'e klant dat it tunneladres fan 'e tsjinner de tunnel yn rûte wurdt. Befêstigje op 'e tsjinner dat d'r in socket bestiet op it adres dat de klant brûkt, en dat it proses dêrefter it iene is dat jo bedoelden.

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/

In harker op 127.0.0.1 sil nea antwurdzje op in fersyk rjochte oan 10.66.0.1, wat de firewall ek tastiet. In harker op it jokeradres sil dat wol, útsein as in regel him blokkearret. De socketlist beslút dus de helte fan 'e gefallen foar't in regel ûndersocht wurdt. Poarte en adres beslisse tegearre oft in fersyk oankomme kin.

Fergelykje it adres dat de klant brûkt mei it adres dat de tsjinner eins op 'e tunnelinterface hat. In ferâldere konfiguraasje oan ien fan 'e kanten produsearret in fersyk dat korrekt nei in pear rûte wurdt dat dat adres net hat.

Pas regels ta foar pleatslike ynfier, net foar trochstjoering

As it pakket oankomt en de socket bestiet, is de oerbleaune grins it ynfierbelied. In regel dy't trochstjoering tastiet, tastiet pleatslike levering net ta, en in regel beheind ta ien interface mat miskien net mei de ferwachte namme fan 'e tunnelinterface.

Test mei ien tastiene poarte nei de bedoelde tsjinst ynstee fan de host te iepenjen. Kontrolearje dan de eigen autorisaasje fan 'e applikaasje: in tastienlist, in akkounteask of in bining oan in bepaald hostnamme kin in fersyk wegerje dat it netwurk mei súkses levere hat.

Hâld sertifikaatkontrôles op har plak. In ûnferwachte sertifikaatidentiteit is ynformaasje oer hokker host antwurde, gjin obstakel om te omzeilen. Der oerhinne klikke ferberget it iene oanwizing dy't de ferkearde tsjinst identifisearret.

Skied namme-, grutte- en identiteitsflatings

In tsjinst dy't op adres wurket mar op namme mislearret, is in DNS-probleem, en de reparaasje heart by de resolverkonfiguraasje dy't nei de klant stjoerd wurdt, net by de firewall. In tsjinst dy't lytse fersiken beantwurdet mar by gruttere antwurden fêstsit, wiist op pakketgrutte en MTU, wat in hiel oar ûndersyk is.

In HTTPS-flater dy't de ferkearde host neamt, betsjut meast dat it fersyk in oare tsjinst berikt hat, faak om't in proxy of in oare harker dy poarte hat. Lês it ûnderwerp fan it sertifikaat en fergelykje it mei de host dy't jo berikke woenen. Dy fergeliking kostet neat en einiget it ûndersyk faak.

Skriuw op hokker kontrôlepunt mislearre: socket, ynfierregel of applikaasjebelied. Dy iene rigel ûnderskiedt in netwurkflater fan in autorisaasjebeslút. It kearet ek dat de folgjende persoan poarten iepenet dy't nea it probleem wiene.