WireGuard peer bat ez da irisgarria beste bat funtzionatzen duen bitartean: kontrol-zerrenda
Funtzionatzen duen peer batek bere gakoa, bere endpoint-a eta bere bideak baino ez ditu frogatzen. Konparatu huts egiten duen peerraren AllowedIPs, habaren birbidaltzea eta barneko iturburua edozein arau zabaldu aurretik.
WireGuard peer batek trafikoa igarotzen du eta bigarren batek esku-uztartzea egiten du baina ez du inoiz tunelaren atzeko ezer lortzen. Funtzionatzen duen peerrak esaten dizu interfazea, UDP ataka eta zerbitzariaren gakoa ziurrenik ondo daudela. Ez dizu ezer esaten bigarren peerraren AllowedIPs-ei, bere barneko iturburu-helbideari edo bien arteko birbidaltze-arau ei buruz. Zerrenda ordenan landu eta baldintza betetzen ez duen lehen urratsean gelditu.
Urratsa 1: Idatzi paketeak jarraitu beharko lukeen bidea
Hab bereko bi bezerok ez dute elkar automatikoki lortzen. Hab eta erradioen diseinuan zerbitzariak paketea wg0-n jasotzen du eta berriro wg0-tik beste peerra birbidali behar du, eta horrek IP birbidaltzea eta birbidaltze-araua eskatzen ditu. Peer-to-peer diseinu zuzenenean alde bakoitzak bestearen endpoint-a eta bestearen tunel-helbidea behar ditu AllowedIPs barruan. Argitu zein diseinu ari zaren arazten edozein konfigurazio irakurri aurretik.
Espero den bideak non begiratu ere esaten dizu. Paketeak haba zeharkatu behar badu, huts egiten duen jauzia bidaltzailearen AllowedIPs, habaren birbidaltzea edo hartzailearen AllowedIPs da. Zuzenean joan behar badu, haba ez da garrantzitsua eta bi peerren endpoint eremuak dira garrantzitsuak.
Urratsa 2: Konparatu AllowedIPs bi aldeetan, ez batean soilik
WireGuard-ek AllowedIPs bideratze-taula eta sarbide-zerrenda gisa erabiltzen du aldi berean. Bidaltzean, helburuko helbidea peerraren AllowedIPs-en bilatzen da tunela aukeratzeko; jasotzean, barneko iturburu-helbidea bidaltzen duen peerraren AllowedIPs barruan egon behar da, bestela paketea baztertu egiten da. Edozein alderekin falta den barrutik sintoma bera sortzen du: garraioa funtzionatzen du, karga desagertu egiten da.
Irakurri zuzeneko egoera fitxategia baino, berriz kargatzeak isilean huts egin baitzezakeen: sudo wg show wg0 allowed-ips. Zerbitzarian, huts egiten duen peerraren sarrerak bere tunel-helbidea izan behar du, adibidez 10.90.0.3/32. Bezeroan, zerbitzariaren peerraren sarrerak probatzen ari zaren helmuga izan behar du, bai habaren tunel-helbidea bai urruneko azpisarea. Barruti gainjarriek bilaketa anbiguoa egiten dute eta nahi ez zenituen peer bat aukera dezakete, beraz, eduki itzazu bereizita.
Urratsa 3: Egiaztatu barneko iturburu-helbidea
10.90.0.3 wg0 bidez bideratzen duen baina bere Wi-Fi helbidetik paketeak bidaltzen dituen bezeroa hartzaileak baztertuko du, iturburua ez baitator bat peerraren AllowedIPs-rekin. Egiaztatu kernak benetan zer aukeratzen duen ip route get 10.90.0.3 from 10.90.0.2 erabiliz, eta egiaztatu tunel-interfazeari esleitutako helbidea ip -brief addr show wg0 erabiliz.
Hartzen duen Linux ostalarian, alderantzizko bidearen iragazketa bigarren atea da. Itzulera-bidearen jabe den interfazean rp_filter zorrotzak tunel-trafikoa bazter dezake, itzulera-bidea iritsi zen interfazearekin bat ez badator. Egiaztatu balio eraginkorra desgaitzen duzun aurretik; topologia askotan konponketa zuzena bidea da, ez iragazki malgutu bat.
Urratsa 4: Berrikusi habaren birbidaltzea eta itzulera-bidea
Habak peerren artean birbidaltzen badu, kernak net.ipv4.ip_forward=1 behar du, eta suebakiak birbidalitako fluxua onartu behar du: sarrera wg0-n, irteera wg0-n, bidaltzailearen tunel-helbidetik hartzailearenera. Hutsegite arrunta UDP 51820 onartzen duen sarrera-araua baina birbidaltze-araua ez izatea] da, beraz esku-uztartzea lortzen da eta karga hiltzen da. Zerrendatu indarrean dauden arauak sudo nft list ruleset edo zure suebaki-kudeatzailearen baliokidearekin.
Ondoren egiaztatu erantzuna. Helburuko ostalariak bidaltzailearenganako itzulera-bidea izan behar du, bai habaren bidez bai bere abio-pasabidearen bidez. Habak tunel-azpisarea NAT bidez itzultzen badu ere, egiaztatu itzulpena birbidalitako fluxuari aplikatzen zaiola eta erantzuna habara iristen dela egoera iraungi aurretik. Gako-problema ematen duen norabide bakarreko hutsegitea itzulera-bide hori besterik ez da izaten askotan.
Azkenik, bereizi esku-uztartzea datuetatik. Esku-uztartzea amaitu baina transferentzia handietan trabatzen den peerrak, normalean, bide horretan bertan MTU edo MSS arazo bat du, ez AllowedIPs arazo bat. Probatu lehenengo ping txiki batekin, gero tamaina osoko batekin, eta konparatu bi peerrak.
Urratsa 5: Aldatu gauza bat eta mantendu funtzionatzen duen peerra osorik
Egin aldaketa bakarra huts egiten duen bidean eta probatu berriro bi peerrak. Peer bakoitzaren AllowedIPs 0.0.0.0/0-rekin ordeztea dagoeneko funtzionatzen zuen peerra hausteko modurik azkarrena da, interfaze horretako trafiko guztiaren bideratze-erabakia aldatzen baitu. Editatu sarrera bakarra, kargatu berriro eta irakurri zuzeneko egoera.
Idatzi zein bidek lortu zuen arrakasta, zeinek huts egin zuen eta bakoitzaren komando-irteera zehatza. Konparazio horrek gehiago balio du VPNa hondatuta dagoelako txosten orokorrak baino, eta hurrengo pertsonak galdetuko duen lehen gauza da.