Dorështrëngimi i WireGuard funksionon, shërbimi jo

Dorështrëngimi përfundon, klienti tregon një numërues të freskët transferimi, dhe megjithatë një kërkesë drejt një shërbimi në të njëjtin server dështon. Ky kombinim i huton njerëzit, sepse tuneli punon në mënyrë të provueshme. Ajo që nuk është provuar është dorëzimi lokal: paketa arriti në host, dhe hosti duhet ende ta pranojë atë në socketin e duhur dhe t'ia kalojë një procesi me leje për t'u përgjigjur. Kaloni nëpër ato tre pika kontrolli me radhë.

Ndaluni te i pari që nuk qëndron, dhe mos shtoni rregulla për të tjerët.

Dorështrëngimi provon vetëm tunelin

Dorështrëngimi i WireGuard vendos çelësa midis palëve dhe autorizon trafikun për intervalet që secila palë renditi. Nuk thotë asgjë për proceset që dëgjojnë në server, dhe as për atë nëse muri i zjarrit i hostit pranon paketa të adresuara drejt një prej adresave të tij.

Pikërisht ky dallim i fundit anashkalohet më shpesh: trafiku drejt vetë hostit është hyrje lokale, ndërsa trafiku që kalon nëpër host drejt diku tjetër është përcjellje. Ato trajtohen nga zinxhirë të ndryshëm të murit të zjarrit dhe cilësime të ndryshme. Kontrolli i zinxhirit të gabuar kushton një pasdite dhe kthen numërues që duken të pafajshëm.

Lexoni dëgjuesin dhe rrugën

Në klient, konfirmoni që adresa e tunelit të serverit rrugëtohet në tunel. Në server, konfirmoni që ekziston një socket në adresën që përdor klienti, dhe që procesi pas tij është ai i synuar.

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/

Një dëgjues në 127.0.0.1 nuk do t'i përgjigjet kurrë një kërkese të adresuar drejt 10.66.0.1, çfarëdo që lejon muri i zjarrit. Një dëgjues në adresën e përgjithshme do t'i përgjigjet, përveç nëse një rregull e bllokon. Lista e socketeve pra zgjidh gjysmën e rasteve para se të shqyrtohet ndonjë rregull. Porta dhe adresa bashkë vendosin nëse një kërkesë mund të arrijë.

Krahasoni adresën që përdor klienti me adresën që serveri ka vërtet në ndërfaqen e tunelit. Një konfigurim i vjetëruar në cilëndo anë prodhon një kërkesë të rrugëtuar saktë drejt një pale që nuk e ka atë adresë.

Zbatoni rregulla për hyrjen lokale, jo për përcjelljen

Nëse paketa arrin dhe socketi ekziston, kufiri i mbetur është politika e hyrjes. Një rregull që lejon përcjelljen nuk lejon dorëzimin lokal, dhe një rregull i kufizuar në një ndërfaqe mund të mos përputhet me emrin e ndërfaqes së tunelit që prisni.

Provoni me një portë të vetme të lejuar drejt shërbimit të synuar, në vend që të hapni hostin. Pastaj kontrolloni autorizimin e vetë aplikacionit: një listë e lejuar, një kërkesë llogarie ose një lidhje me një emër hosti të caktuar mund të refuzojnë një kërkesë që rrjeta e dorëzoi me sukses.

Mbajini kontrollet e certifikatës në vend. Një identitet i papritur certifikate është informacion për atë se cili host u përgjigj, jo një pengesë për t'u anashkaluar. Kalimi me klik mbi të fsheh të vetmen gjurmë që identifikon shërbimin e gabuar.

Ndani dështimet e emrit, madhësisë dhe identitetit

Një shërbim që punon sipas adresës por dështon sipas emrit është problem DNS, dhe rregullimi i takon konfigurimit të zgjidhësit që dërgohet klientit, jo murit të zjarrit. Një shërbim që përgjigjet për kërkesa të vogla por ngec në përgjigje më të mëdha tregon madhësinë e paketës dhe MTU, që është një hetim krejt tjetër.

Një gabim HTTPS që emërton hostin e gabuar zakonisht do të thotë që kërkesa arriti një shërbim tjetër, shpesh sepse një proxy ose një dëgjues tjetër zotëron atë portë. Lexoni subjektin e certifikatës dhe krahasojeni me hostin ku donit të arrinit. Ky krahasim nuk kushton asgjë dhe shpesh e mbyll hetimin.

Shënoni cila pikë kontrolli dështoi: socketi, rregulli i hyrjes apo politika e aplikacionit. Ai rresht i vetëm dallon një defekt rrjeti nga një vendim autorizimi. Ai gjithashtu pengon personin tjetër të hapë porta që nuk ishin kurrë problemi.