WireGuardek zerbitzariak bidali ondoren soilik funtzionatzen du: muturreko puntuaren ezagutza

Tunela zerbitzariak lehenengo zerbait bidali ondoren soilik funtzionatzen ari dela dirudi. Hasi bezeroaldetik eta ezer ez da gertatzen, itxaron segundo batzuk, saiatu berriro eta lortzen du. Ohiko diagnosia NAT hautsia da, eta ohiko diagnosia okerra da. Aldatu dena hau da: bikote batek besteak non bizi den ikasi duela.

Muturreko puntuaren ezagutza, ez irisgarritasuna

WireGuard bikote batek ez du esku-ematerik hasiko nora bidali jakin arte. Konfigurazioak helbide eta atakako muturreko puntu gisa ematen du hori, eta martxan dagoen egoerak orain sinesten duen muturreko puntua jarraitzen du.

wg show irudi horren bi aldeak erakusten ditu, eta irteeran muturreko punturik ez duen bikoteak ezin du ezer hasi, bere gako publikoa eta onartutako aurrizkiak zenbat eta zuzenago egon. Alderatu bezeroaren ikuspegia zerbitzariarekin edozein arau aldatu aurretik, askotan ez baitatoz bat nork zer dakin.

Nola ikasten duen bikote batek muturreko puntu bat

WireGuard isila da nahita. Autentifikatutako pakete zuzena bikoteak espero ez zuen helbidetik iristen denean, inplementazioak bikote horren muturreko puntua iturri berrira eguneratzen du, eta horrela funtzionatzen du sarez aldatzen duen eramangarri batean ibiltzeak. Jokabide horrek norabidearekiko dependentzia azaltzen du: zerbitzariak lehenengo bidaltzen badu eta bere paketea bezeroarenera iristen bada, bezeroak zerbitzariaren uneko helbidea ikasten du eta erantzun dezake. Harik eta ordu arte ez du nora bidalirik. Mekanismoa autentifikatutako ibiltzea da, ez lehen erabilerako konfiantza-lasterbidea, paketeak baliozkoa izan behar baitzuen muturreko puntua mugitu aurretik.

wg tresnaren dokumentazioak eguneratze hori deskribatzen du, eta behin irakurtzea merezi du horren inguruan diseinatzeko asmoa baduzu.

Egoera duen itzulpenak bere norabidea gehitzen du

UDP itzultzen duen ataka baten bidez pasatzen denean, atakak egoera sortzen du ikusten duen lehen paketearentzat. RFC 4787 dokumentuak jokabide hori eta mapaketa azkenean kentzen duten denbora-mugak deskribatzen ditu. Mapaketa inaktiboa iraungitzen da, eta urrutiko aldetik datorren sarrerako paketea atakak baztertzen du orduan ostalarira iritsi aurretik. Goiz osoan funtzionatu duen tunel batek arratsaldean erantzuteari uzten dio arrazoi zehatz horregatik.

Hau bigarren mekanismo independentea da, norabide-sintoma bera sortzen duena. Muturreko puntuaren ezagutzak eta itzulpen-egoerak biak zuzen egon behar dute, eta bat konpontzeak ez du bestea konpontzen.

Konfiguratu benetan nahi duzun norabidea

Konexioa hasi behar duen bezero batentzat, jarri zerbitzariaren muturreko puntua bezeroaren bikoteen atalean eta utzi han. Zerbitzariak lehenengo bidaliko duela fidatzea trafikoaren ordenaren ustekabean fidatzea da, sare isil batean aldatuko dena. Konfigurazioak asmo den norabidea adierazi beharko luke, ez aurkitu.

Itzulpen baten atzean egon eta irisgarri jarraitu behar duen bikote batentzat, gaitu keepalive iraunkorra alde horretan. 25 segundo oro keepalive bat ohiko hasierako balioa da, eta bere helburua mapaketa irekita edukitzea da, ez tunela probatzea. Aukeratu alde bat hura eramateko, bi aldeetan gaitzeak trafikoa eta erregistroaren zarata bikoizten baititu emaitza hobetu gabe.

Alderatu egoera eragilearen aurretik eta ondoren

Hartu bi ikuspegiak huts egiten duen unean, eta gero berriro zerbitzariak bidali ondoren. Lehen komandoak muturreko puntuak eta esku-ematearen adina erakusten ditu. Bigarrenak atakarentzako itzulpen-sarrerarik badagoen erakusten du. Harrapaketak zein norabidek zeharkatu zuen kablea erakusten du, eta ibilbide-egiaztapenak baieztatzen du bezeroak ez duela trafiko hori beste leku batera bidaltzen.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Idatzi muturreko puntuaren zutabea eta itzulpen-sarrera elkarrekin. Muturreko punturik ez duen bikotea eta mapaketarik ez duen ataka bi akats desberdin dira. Horietako bat soilik konpontzen du keepalive batek.