WireGuard bezeroak ezin du OpenVPN bezero batengana iritsi?

Bi tunelak konektatzen dira, bezero bakoitzak atebidera iristen da, eta batek bestearen helbidea probatzen duen unean paketeak desagertu egiten dira. Bi eskuko keinuetan ez dago ezer gaizki, eta gakoak berriro igortzeak ez du hori aldatzen. Atebideak bere bi interfazeen artean IP pakete arruntak eramaten ditu zifratu gabe, beraz protokoloek ez dute inoiz elkar ulertu behar; behar dutena eskuko keinuek ematen ez duten hiru gauza dira. Helmugaren estaldura jatorrizko bezeroan, iturriaren jabetza atebidean eta itzulera-bidea urruneko aldean. Sintoma hirurentzat bera da, horregatik diagnostikatzen dira elkarrekin.

Sintomari zati bat falta zaio aldi bakoitzean

Diseinu honek 10.71.0.0/24 WireGuard gunea erabiltzen du wg1 interfazean eta 10.72.0.0/24 OpenVPN gunea tun1 interfazean, biak atebide bakarrean amaitzen direlarik. Proban dagoen eskaera 10.71.0.5 helbidetik 10.72.0.30 helbideko HTTPS-ra joaten da. Beheko urrats bakoitza fluxu bakar horri buruzkoa da. Egiaztapen bakoitzak huts-egiaztagiri desberdina du, erabiltzaileak berdin bizi dituen arren, eta normalean hiruretatik bat baino ez da falta aldi berean.

Hasi baieztatzen bi guneak benetan atebide honetan daudela eta birbidalketa gaituta dagoela tunelek bizi diren izen-espazioan. Bi protokoloak izen-espazio desberdinetan amaitzen dituen atebideak ez du euren artean ezer birbidaltzen, eta hori baztertzea merezi du pare baten konfigurazioa irakurri aurretik.

Zabaltu erradioaren helmugaren estaldura

WireGuard bezeroan, lehendik dagoen pare-erregistroak atebidea hautatu behar du OpenVPN helmugarako, hau da, helmugako aurrizkiak pare horren baimendutako zerrendan agertu behar du. Hura gehitzeak ez du bigarren tunel bat sortzen; bezeroak helbide hori bilatzean zein pare hautatzen duen aldatzen du, eta wg-quick erabiliz gero ibilbideak zerrenda automatikoki jarraitzen du normalean.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Utzi giltza eta amaiera-puntuko benetako lerroak ukitu gabe, eta gogoratu Table = off erabiltzen duen kudeatzaileak ez duela zerrenda honetatik ibilbiderik hartzen. Kasu horretan aurrizki berak sistemaren ibilbide-taulan instalatu behar du jabea denak, eta han falta den ibilbideak baimendutako aurrizki bat falta balitz bezala dirudi.

Mantendu iturriaren jabetza atebidean

Bezero honen pare-erregistroak atebidean bezero horren iturri-helbidea zehazki edukitzen jarraitu behar du. Baimendutako helbideak bi noranzkoetan egiaztatzen dira: irteerako trafikorako pare bat hautatzen dute eta sarrerako pakete baten iturria bidali zuen parearena dela balioztatzen dute. OpenVPN gunea erradioaren erregistroan jartzea, erradioak hara iritsi nahi duelako, trafikoa partaide okerrengana bidaltzen duen akatsa da.

AllowedIPs = 10.71.0.5/32

Irakurri erregistro hori jabetza-adierazpen gisa, ibilbide-erraztasun gisa baino. Bezeroak iritsi behar duen beste edozein gauza bezeroaren helmuga-zerrendan dago, ez atebideak pare honek zer bidal dezakeen pentsatzeko duen eran.

Eman OpenVPN aldeari itzulera-ibilbidea

Helmugak WireGuard iturrira itzultzeko ibilbidea behar du orain, eta gune-bezeroentzat OpenVPN zerbitzaritik bultzatutako ibilbide gisa iristen da normalean. Bultzatu behar duten bezeroei bakarrik, eta berretsi bezeroan onartu dela, direktiba aplikatu dela suposatu beharrean.

push "route 10.71.0.0 255.255.255.0"

Ibilbideen banaketa ez da baimen-ematea. Helmuga gunean egon beharrean beste OpenVPN bezero baten atzean dagoenean, bezero horren beraren LAN jabetza eta birbidaltze-baldintzak diseinuari gehitzen zaizkio, eta bultzatutako ibilbidea lehen erdia baino ez da. Berrformulatu baldintza grafo gisa direktibak gehitu aurretik: zein nodok zein aurrizki duen eta zein nodok hara birbidaltzen duen.

Baimendu baimendu nahi zenituen zerbitzu bakarra

Birbidalketa gaituta eta bi guneak bideragarriak izanda, geratzen den galdera politika da. Idatzi araua fluxu zehatzerako, ez interfaze-bikotearentzat oro har, aurreikusi aplikatu aurretik, eta mantendu egoera duen itzulera-bidea, erantzunak konexio berri gisa blokeatu ez daitezen. Probealdiak ez du ezer kostatzen eta zer gehituko litzatekeen erakusten du.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Hauek birbidalitako arauak dira, atebidearen bi VPN zerbitzuen entzute-arauetatik bereiziak. Kanpoko UDP portuak irekitzeak ez du barneko eskaera baimenduko, eta barneko eskaera baimendu behar izateak ez du atebidera mugarik gabeko SSH edo birbidalketan isileko baimenik eskatzen. Helburuaren beraren suebakiak eta entzute-helbideak bat etorri behar dute, loopback-era lotuta dagoen zerbitzuak ikaratutako pakete zainduena ere ukatzen duelako. Elkarrizketaren noranzko bakarra besterik estaltzen ez duen politikak huts egiten du eskaera arrakastatsu eta erantzun isil batekin, hiru emaitzetatik nahasgarriena.

Ibilbide elkarrekikoak normalean iturri-itulpenik behar ez dela esan nahi du, eta horrek WireGuard helbidea helburuan gordetzen du eta erregistroak irakurgarri egiten ditu. Ez gehitu masifikazio orokorrik bi protokolo daudelako, eta ez kendu lehendik dagoen itulpen-arau bat hark zer duen mendeko jakin gabe. Ondoren egiaztatu fluxu bakarra hasieratik amaierara, eta probatu baimenduta ez dagoen iturri edo port bat ere: alde bakoitzean funtzionatzen duen eskuko keinuak ez du ez bide gurutzatua ez isolamendua frogatzen.