WireGuard i ndërthurur: hopi i mesëm nuk mund t’i përgjigjet portës së vet
Kur hopi i mesëm dërgon gjithçka në një tunel të vetëm, përgjigjet për shërbimin e tij hyrës dalin në rrugën e gabuar. Një rregull e portës burimore në ndërfaqe e rregullon këtë.
Tre hop WireGuard arrijnë në një rrjet pa adresë publike, dhe pastaj makina e mesme ndalon së përgjigjuri në portën ku duhej të dëgjonte. Tuneli përpara vazhdon të funksionojë, hosti i largët vazhdon të përgjigjet, dhe vetëm serveri i mesëm është heshtur nga jashtë. Ai kombinim është konfuz pikërisht sepse është i vetëshkaktuar: hopi i mesëm i bindet tabelës së vetë rrugëtimit, dhe tabela i dërgon përgjigjet e tij në drejtimin e gabuar.
Një zinxhir që funksionon derisa të flasësh me kutinë e mesme
Merrni një zinxhir ilustrues: klienti A arrin serverin B në UDP 500, dhe B vazhdon më tej te serveri C në UDP 500. C pranon trafik vetëm nga adresa e partnerit të tij të vetëm, gjë që e bën atë një gjethe dhe e mban sjelljen e tij të thjeshtë. B nuk është gjethe, dhe çdo gjë interesante për këtë dështim ndodh atje.
Dallimi ka rëndësi sepse rolet e gjethes dhe të mesit tërheqin në drejtime të kundërta. Një gjethe mund të dërgojë gjithçka në një tunel të vetëm pa pasoja, pasi asgjë tjetër nuk varet nga ajo. Një hop i mesëm është njëkohësisht pikë fundore për klientët dhe klient drejt anës së largët, dhe këto dy punë duan rrugëtim të ndryshëm.
Pse përgjigjja del përmes tunelit
Në B, ndërfaqja që shikon nga C mban AllowedIPs = 0.0.0.0/0 së bashku me rrugën e paracaktuar përkatëse. Prandaj çdo paketë që krijon B hyn në atë tunel, përveç nëse diçka më konkrete ka përparësi.
Një paketë nga A e drejtuar te B arrin dhe pranohet, sepse B është destinacioni dhe dorëzimi lokal ndodh i pari. Përgjigjja është një paketë plotësisht e re e krijuar lokalisht dhe e drejtuar kah adresa publike e A, dhe ai destinacion përputhet me rrugën e paracaktuar në tunel. C e merr atë, nuk e zotëron këtë adresë dhe e hedh.
Simptoma lexohet si problem muri zjarri ose mospërputhje çelësi, dhe asnjëra nuk është e vërtetë këtu. Një kapje në tunelin drejt C tregon se përgjigjet shkojnë në drejtimin e gabuar. Ai vëzhgim i vetëm kursen më shumë kohë sesa çdo sasi leximi i konfigurimit, prandaj shënojeni përpara se të filloni të ndryshoni çelësat. Kush nuk e ka parë kapjen do të supozojë se vetë tuneli është prishur.
Rregullimi i ngushtë: rregulla politike që përputhen me një portë burimore
Përgjigjet nga socket-i dëgjues i B dalin me portën burimore 500. Një rregull politike mund të përputhet me këtë dhe t’i kthejë ato paketa në tabelën e zakonshme:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101Rregullat politike konsultohen sipas rendit të përparësisë, dhe tabela kryesore ndodhet në 32766, kështu që një rregull në 100 pyetet përpara se rruga e paracaktuar e tunelit të thotë gjënë e vet. Shtoni një hyrje për çdo portë që duhet të mbetet e arritshme nga jashtë dhe asgjë më shumë, që trafiku i përcjellë të vazhdojë të përdorë tunelin për të cilin u ndërtua.
Njihni kufirin e këtij truku. Përzgjedhësi sport përputhet me paketa të krijuara lokalisht, gjë që mbulon saktësisht rastin e përgjigjes dhe me dashje nuk mbulon trafikun që B thjesht përcjell për dikë tjetër. Një shërbim i strehuar pas B ka ende nevojë për përgjigjen e vet, dhe të pretendosh të kundërtën prodhon një rregullim që funksionon për shërbimin e parë dhe dështon për të dytin.
Jepini rregullit një pronar
Një rregull i shkruar në një prompt zhduket herën tjetër kur ndërfaqja rindërtohet. Në një konfigurim WireGuard, vendoseni atje ku ndërfaqja krijohet dhe hiqet:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Nëse ndërfaqja zotërohet nga NetworkManager, një grep i shpërndarjes ose një pikë hyrëse kontejneri, çifti i përket atij pronari dhe jo një skedari të redaktuar me dorë. Kontrolloni rregullat efektive pas një rilidhjeje, jo vetëm pas nisjes së parë, sepse nisja e parë është rasti që funksionon gjithmonë.
Krahasoni alternativat me ndershmëri
Rregulli i portës burimore është një nga katër rrugëdaljet, dhe më i ngushti prej tyre. Ka avantazhin se nuk e prek fare politikën e tunelit, prandaj zakonisht i mbijeton ndryshimeve të mëvonshme. Rregullimet e ngushta dështojnë gjithashtu me zë kur pushojnë së vlefshmi, ndërsa një përjashtim i gjerë vazhdon të punojë në heshtje shumë kohë pasi arsyeja e tij është zhdukur. Ai dallim ka më shumë rëndësi sesa eleganca kur pas dy vjetësh kutinë e zotëron dikush tjetër.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Verifikoni nga të dy skajet pasi të keni zgjedhur. Nga A, nisni një lidhje drejt portës së B dhe mbajeni të zënë për një kohë. Në B, bëni bërthamën të justifikojë rrugën e përgjigjes me diçka si ip route get <address-of-A> sport 500, dhe konfirmoni se emërton ndërfaqen WAN dhe jo tunelin. Pas kësaj, kontrolloni që diçka pas C përsëri përgjigjet përmes zinxhirit, gjë që provon se përjashtimi mbeti i ngushtë në vend që të bëhej anashkalim. Së fundi, shënoni portat në shënimet e projektimit, përndryshe operatori i radhës do ta rizbulojë këtë në një shërbim tjetër.