WireGuard-en handshake-a funtzionatzen du, baina ez dago internetik: jarraitu paketea
Handshake-ak gakoak eta irisgarritasuna baino ez ditu frogatzen. Jarraitu pakete bat AllowedIPs-tik aurrera birbidalketa, NAT eta itzulera-bidetik zehar, non gelditzen den ikusteko.
Tunela martxan dago, wg show-k duela gutxiko handshake bat erakusten du, zerbitzariaren tunel helbidera ping egin dezakezu, eta haratago ezerk ez du erantzuten. Senak gakoak berriz sortzeko edo konfigurazioa berriz partekatzeko esaten du. Hori dagoeneko funtzionatzen duela frogatuta dagoen bide-zati zehatza aldatzea da.
Osatutako handshake batek esaten du bi aldeak gakoetan ados daudela, UDP-k muturrera iristen dela eta kripto-bideratzeak paketea onartzen duela. Ez du ezer esaten paketea gero zerbitzaritik irten daitekeen ala ez.
Beraz, jarraitu pakete bat asmatu beharrean. Lau leku daude non hil daitekeen, eta bakoitzak arrasto desberdina uzten du.
Zer frogatzen duen handshake-ak benetan
WireGuard UDP protokoloa da: Noise handshake batekin saioa ezartzen du eta gero paketeak zifratzen ditu beste aldearentzat. wg show-k segundo gutxiko handshake bat eta hazten ari den transferentzia-kontagailu bat erakusten dituenean, muturra, gakoak eta beste aldearen gako publikoa zuzenak dira guztiak.
Frogatzen ez duena da zure bezeroak interneteko trafikoa interfazera bidaltzen duenik ere, zerbitzaria hura birbidaltzeko prest dagoenik edo erantzun batek itzulerako bidea aurki dezakeenik. Hori kernelaren bideratze-erabakiak eta suebakiarenak dira, eta tunelaren kanpoan hartzen dira.
Horregatik da hain proba engainagarria zerbitzariaren tunel helbidera ping egitea. Pakete hori zerbitzariari berari zuzenduta dago, beraz bertan amaitzen da. Inoiz ez du birbidalketarik behar, inoiz ez itzulpenik eta inoiz ez internetetik itzulerako biderik.
AllowedIPs bideratze-erabakia da
Bezeroan, AllowedIPs-k bi lan egiten ditu. Gako kriptografikoko bideratze-taula da, zein helmuga-helbide beste alde honen tunelera bidaltzen diren erabakitzen duena, eta beste aldeak zuregandik onartuko dituen iturburu-helbideen zerrenda da. Bezeroaren konfigurazioak 10.8.0.0/24 baino ez badu zerrendatzen, helmuga publikoak ez dira inoiz interfazera sartzen eta zure ohiko bide lehenetsiak tunelaren kanpora eramaten ditu. Orduan tunelak primeran funtzionatzen du eta nahi zenuen ezer ez du egiten.
Begiratu bezeroak benetan zer instalatu zuen, konfigurazio-fitxategiak dioenaren ordez:
wg show wg0 allowed-ipsip route get 1.1.1.1
Bigarren komandoa da erabakigarria. Erantzunak zure interfaz fisikoa eta ohiko atea aipatzen baditu, paketea ez da tunelen bidez igarotzen eta zerbitzariaren aldeko aldaketak ez du konponduko. Gehitu 0.0.0.0/0 IPv4-rako eta ::/0 IPv6-rako bereizita; familia baterako dena hartzen duen arauak bestea bere jatorrizko bidean uzten du, eta hori ohiko arrazoia da IPv4 tunel bat funtzionatzeko eta IPv6 bilaketa bat trabatzeko.
Non hiltzen den paketea atean
Bidea zuzena bada eta paketea oraindik inora ez badoa, zerbitzarira iristen da eta han gelditzen da. Lau egiaztapenek ate gehienak hartzen dituzte.
Birbidalketa. sysctl net.ipv4.ip_forward-k 0 itzultzea erantzun klasikoa da, eta banaketa askok oraindik 0 dute lehenetsita. 1 izan behar du, eta sysctl fitxategi batean ezarri behar da iraunkorki, berrabiaraztean desagertzen den komando baten ordez. IPv6 birbidalketa etengailu bereizia da.
Iragazte-politika. Lehenetsitako drop politikako FORWARD kate batek tunelaren trafikoa baztertuko du, ostalari berari zuzendutako trafikoa onartzen duen bitartean, eta horrek sintomarekin bat egiten du zehazki. Irakurri zuzeneko arau-multzoa, ez gordetako fitxategia: nft list ruleset edo iptables -S.
Itzulpena edo bideratzea. Tunel helbide pribatuak erabiltzen dituzten bezeroek zerbitzariaren irteera-interfazean iturburu-NAT behar dute, edo goiko sareak itzultzen dakien bideratutako aurrizki bat. Bien arteko hautaketa helbide-planari jarraitzen dio. Zure aurrizkia jada itzultzen duen sare batean MASQUERADE gehitzea kaltegabea da baina alferrikakoa, eta biderik ez dagoen lekuan alde batera uzteak erantzunak bideratu ezin den barruti pribatu batera zuzenduta uzten ditu.
Itzulerako bidea. Bideratutako diseinuetan, goiko bideratzaileak zure zerbitzarira seinalatzen duen bide bat behar du. Hornitzailearen sareak ere blokea dezake: hainbat hodeik iturburu eta helmuga egiaztapena aktibatzen dute instantzian, eta horrek isil-isilik baztertzen ditu iturburua instantziaren beraren helbidea ez duten paketeak, egiaztapen hori desgaitzen den arte.
DNSak bideratzeak ez bezala huts egiten du
Helbide ezagun baterako pakete bat eta izen-bilaketa bat huts egite desberdinak dira, eta errore-mezuak kontrako norabideetan engainatzen dute. ping 1.1.1.1-k funtzionatzen badu eta nabigatzaileak ezer kargatu ezin badu, bidea ondo dago eta izen-ebazpena ez. Ping-ak berak huts egiten badu, DNS ez da garrantzitsua eta aurreko atalera itzuli zara.
wg-quick-ek resolver bat ezar dezake konfigurazioko DNS = lerrotik, eta systemd-resolved-ek bere portaera du esteka bakoitzeko. Resolver-a tunelaren barruan soilik irisgarria den helbide batekin gainidazten duen VPN batek bilaketa guztiek huts egingo dute tunela erortzen den unean, eta horrek tunelak internet hausten duela ematen du.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Frogak ematen dituen ordena
Egin bezeroaren aldeko egiaztapena lehenengo, komando bakarra delako eta aukeren erdia ezabatzen duelako. Egiaztatu gero zerbitzaria interneterako irteera izateko pentsatuta ote dagoen; sarbide pribaturako eraikitako ate bat ez dago hautsita helmuga publikoek huts egiten dutenean.
Zerbitzarian, begiratu interfazeari bezerotik ping bidaltzen duzun bitartean: tcpdump -ni wg0 icmp-k eskaera erakutsi beharko luke, eta tcpdump -ni eth0 icmp-k ateratzen ari dela erakutsi beharko luke, itzulia edo ez. Lehenengoan agertu eta bigarrenean inoiz ez bada, geldialdia zerbitzariaren tokikoa da. Ateratzen bada eta erantzunik itzultzen ez bada, arazoa gorago dago, eta hori beste elkarrizketa bat da.
Azkenik, egin konponketak berrabiarazte bat gaindi dezan. Birbidalketa sysctl fitxategi batean dagokio, suebakiaren arauak kargatzen dituen zerbitzuan, eta bezeroaren bideak interfazea altxatzen duen konfigurazioan, ahaztuko duzun shell batean beharrean. Konektatu berriro, errepikatu proba berak eta egiaztatu kontagailuak mugitzen direla.