OpenVPN bidezko aurrizki publikoa: itzultzeko bidea konpondu

Ikusi tunela altxatzen eta bezeroak beste aldea pingatzen duela, eta gero VPNaren atzean dagoen helbide publiko batek beste nonbaitetik erantzuten du, edo ez du batere erantzuten. Sintoma horrek ez du normalean zerikusirik zifratzearekin edo ziurtagiriekin. Hornitzaileak bideratutako aurrizkia IP bide gisa entregatzen da, eta hura OpenVPN bidez eramateak bide hori bi mailetan erreproduzitzea eta itzultzeko bidean jatorrizko helbidea gordetzea esan nahi du. Ez da WANa zubiratu behar, eta helbidea interfaze bati gehitzeak ez du goranzko bidea sortzen.

Aurrizkia lehenengo zuregana bideratu behar da

Galdegin hornitzaileari blokea nola entregatzen den. Zure zerbitzariaren helbide nagusira bideratutako aurrizkia WAN segmentu batean zuzenean iristea hornitzaileak espero dituen helbideetatik desberdina da. Hemen deskribatutako diseinuarekin lehenengo modeloak bakarrik funtzionatzen du.

Hornitzaileak 198.51.100.64/28 zure sarrera-zerbitzarira bideratzen badu, tarte horretako paketeak zerbitzarira iristen dira eta han gelditzen dira, zuk birbidaltzen ez badituzu. Hornitzaileak tartea zure uplinkera zubiratzen badu aldiz, zerbitzariak ARP erantzun behar dio, eta hori beste arazo bat da.

Proba ezazu entrega-eredua OpenVPN ukitu aurretik: kanpotik, egin ping blokeko helbide bati eta ikusi zein interfazek hartzen duen. Ezer iristen ez bada, tunel-konfigurazioak ez du lagunduko. Helbideak WANean zuzenean erantzuten badu, hornitzailea zubiratzen ari da, ez bideratzen, eta beheko diseinua ez da aplikatzen.

Bi bideratze-maila: kernel bidea eta iroute

OpenVPNek aurrizkia bi lekutan behar du. Kernelak jakin behar du aurrizkia tunel gailuarena dela, birbidalitako paketeak OpenVPNera sartu daitezen lehenetsitako bidean sartu beharrean. OpenVPNek ere jakin behar du zein bezero autentifikatuk duen aurrizkia, eta hori da bezeroaren direktorioan dagoen iroute sarrera.

Zerbitzariaren aldeko bideak itxura hau du, aurrizkiak eta maskarak esleipenarekin bat egin behar dute:

ip route add 198.51.100.64/28 dev tun0

Bezeroari dagokion konfigurazioak jabetza esleitzen du. Jarri bezeroaren ziurtagiriaren izen arruntaren arabera izendatutako CCD fitxategian, eta egiaztatu karpeta hori dela zerbitzariak benetan irakurtzen duena:

iroute 198.51.100.64 255.255.255.240

OpenVPNen bideratutako sareei buruzko dokumentazioak bi mailak eta zergatik diren bereiziak deskribatzen ditu. iroute gabe kernel bide batek paketeak jaberik gabe bidaltzen ditu tunelera, eta OpenVPNek baztertu egiten ditu. Kernelen biderik gabeko iroute batek paketeak zerbitzariaren bide lehenetsian uzten ditu. Bi erroreek tunel hautsia dirudite bezeroaren aldetik.

Non bizi den zerbitzuaren helbidea

Delegatutako aurrizkia ez da tunelaren beraren helbideekin gauza bera. Zenbakitu esteka espazio pribatutik nahi baduzu, eta jarri zerbitzuaren helbide publikoa zerbitzua benetan exekutatzen den lekuan.

Zerbitzua tokian bertan amaitzen duen Linux bezero batean, host helbide bakar bat nahikoa da:

ip address add 198.51.100.70/32 dev lo

Aurrizkia VM host batera edo beste LAN batera bideratzen bada, konfiguratu beherako bide hori eta haren itzultzeko bidea horren ordez. Ez da beharrezkoa blokeko helbide guztiak VPN bezeroari esleitzea, eta gatazkak sortzen ditu geroago.

Mantendu jatorri publikoa itzultzeko bidean

Delegatutako aurrizkitik datorren erantzunak tunelaren bidez irten eta hornitzailearen bidera iritsi behar du. Urrutiko hostak bere ISParen bidez bidaltzen badu, jatorrizko helbidea faltsua dirudi, eta hornitzaileak edo helburuak baztertu egiten du. Konponbidea jatorrian oinarritutako araua edo bideratze-taula dedikatu bat da, ez NAT zabalagoa. Hori gabe, zerbitzuak tunelaren parekoarekin funtzionatzen du eta beste edozein lekutatik huts egiten du.

Sarrera-zerbitzarian, masquerade arau zabal bat da errudun ohikoa. Jatorri publikoa zerbitzariaren helbide nagusira berridazten du, eta bezeroak ez du inoiz benetakoa ikusten:

iptables -t nat -S POSTROUTING

Mugatu NAT behar duten VPN bezero pribatuei eta utzi delegatutako aurrizkia itzuli gabe. Gero egiaztatu zerbitzariak aurrizkia batere birbidaltzen duen, lehenetsitako ukapeneko birbidaltze-kate batek isilpean baztertzen baitu.

Egiaztatu bi norabideak fidatu aurretik

Egiaztapena lau behaketa dira, ez bat. Egiaztatu hornitzailearen bidea iristen dela, kernelak aurrizkia tunelera bidaltzen duela, OpenVPNek bezero egokirari egozten diola, eta erantzuna jatorri publikoarekin osorik itzultzen dela. Behaketa bakoitzak bere komandoa du, beraz hutsegite batek geruza bat seinalatzen du, ez diseinu osoa. Exekutatu horiek ordena horretan konfigurazio-aldaketa bakoitzaren ondoren.

Galdetu kernelari bide zein hartzen duen helbide delegatu batek, eta behatu tunela eskaera bat exekutatzen ari den bitartean:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Alderantzizko bidearen iragazketak bide zuzena baliogabetu dezake. Egiaztatu ezarpen efektiboa tunelean eta uplinkean, eta gogoratu modu zorrotzak baztertu egiten duela jatorria iritsi den interfazearekin bat ez datorren trafikoa:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Azkenik, probatu hutsegite-kasua. Gelditu tunela eta egiaztatu aurrizki publikoak ez duela uplink arruntetik ihes egiten. VPNa leheneratzeak zerbitzua itzuli beharko luke, hostak zein portu erakusten dituen zabaldu gabe.