Nola bihurtzen den NAT atzeko OpenVPN bezero bat interneteko irteera

Hiru Linux ostalari, diseinu bat: publikoki irisgarria den OpenVPN zentro bat, kontsumitzailearen eramangarri bat eta sarrerako ezer birbidaltzen ez duen etxeko bideratzaile arrunt baten atzean dagoen irteera-makina bat. Irteerak berak deitzen du zentrora. Gero kontsumitzailearen internet-trafikoak tunelera sartzen da eramangarrian eta irteeraren bere goiko estekatik ateratzen da. Konfigurazio honetan harrigarria den guztia xehetasun batetik dator: irteerak hasi zuen konexioa, beraz barruranzko bidea jada badago eta ez da portu-birbideratzerik behar hura sortzeko.

Hurrengoak paketearen bidea jarraitzen du, ez konfigurazioaren ordena, konfigurazioak zentzua baitu osagai bakoitzak zein erabaki hartzen duen jakin ondoren. Geruza bakoitzak erabaki bat zehazki hartzen du, eta erroreak bi geruza bat bezala hartzen diren lekuan pilatzen dira.

Bi garraio-saio, barne-bide bat

Ostalariek bakoitzak bere kanpoko konexioa du zentrora, eta horietako inork ez daki besteaz. Kontsumitzailearen interneteko trafikoa barne-fluxu bereizia da, kontsumitzailearen tunelean garraiatzen dena eta gero irteeraren tunelatik berriro igortzen dena. Fluxu hori da zentroak bideratu behar duena eta irteerak birbidali behar duena.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Kanpoko bi konexioak bezeroaren aldetik irteten direnez, irteeraren bideratzaileak ez du inoiz sarrerako SYNik ikusten eta ez du inoiz helburuko NAT erregelarik behar. Ezartzen den garraioa bizirik mantendu behar du soilik, eta hori jada egiten du edozein konexio luzeetarako. Internet publikoan ezerk ez du aurretik irteera ukitu behar, horregatik goiko esteka horretako helbide dinamikoa ez da arazoa. Bideratzaileak irteerako saioa baimendu behar du oraindik, baina nabigatzaileak jada erabiltzen duen baimena da.

Zer instalatzen duen iroute-k benetan zerbitzariaren barruan

Zentroa da pare bat zein helbururen jabe den erabakitzen duen gailu bakarra, eta erabaki hori bere erabiltzaile-espazioko bideratze-taulan hartzen du, ez kernelarenean. Irteerarako exit-node izeneko client-config-dir sarrera batek lehenetsitako aurrizkia aldarrikatu dezake han:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Lerro horrek zerbitzari-prozesuari esaten dio "helmuga edozein duten barne-paketeak bezero honenak dira". Ez du bide lehenetsirik gehitzen zentroaren sistema eragilean eta ez du zentroa interneteko atari bihurtzen. OpenVPN 2.6 erreferentzia bezeroaren barne-bideratzea eta kernelaren bideratzea mekanismo bereizi gisa mantentzen ditu, eta bereizketa hori da diseinuak zentroaren bide lehenetsia ukitu gabe funtzionatzeko arrazoia.

Kontsumitzaileak ispilu-iruzkina behar du, push gisa emana, bere trafikoak tunelera sar dadin bere atari lokaletik atera beharrean. Azpisare topologiarekin igerilekua irteeraren tun gailuan konektatutako bidea da, beraz itzulera-noranzkoak ez du push gehigarririk behar; irteerak jaso behar ez duena beheko berbideratzea da, bere goiko estekako trafikoa erabili nahi duen tunelera itzuliko bailuke. Bidali soilik kontsumitzaileari eta irakurri aplikatutako bideak bezeroan, CCD fitxategia hautatu dela fidatu beharrean.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Irteeraren kernelak egiten du birbidalketa

Irteeraren barruan, kontsumitzailearen pakete bat tun interfazean iristen da interneteko ostalari batera zuzenduta. Kernelak bere bideratze-taula kontsultatzen du, egiazko goiko esteka aurkitzen du bat-etortze onena gisa, eta gero bi politika independente aplikatzen ditu: pakete hau birbidal daitekeen eta interfaze horretatik helbide horrekin irten daitekeen. Birbidalketa sysctl bat da eta banaketa askotan lehenespenez desaktibatuta dago.

Beraz irteerak IPv4 birbidalketa etengabe gaituta behar du, kontsumitzailearen tunel-iturriak goiko estekarantz onartzen dituen birbidalketa-erregela bat eta tun bidezko erantzun-bidea. Ostalari osoarentzat birbidalketa gaitzeak haren bidez bideratzen den beste guztiaren portaera ere aldatzen du, horregatik erregelak iturriak eta interfazeak izendatu beharko lituzke dena onartu beharrean.

Iturriaren itzulpenak erosten du itzulera-bidea

Interneteko ostalariek ez dute 10.90.0.x helbide baterako biderik, beraz erantzunak baztertuko lirateke irteerara iritsi aurretik. Iturria berridaztea paketea goiko estekatik irtetean konpontzen du hori, eta konexio-jarraitzeak berridazketa alderantzikatzen du itzuleran.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Goiko erregela goiko estekako interfaze baterako abiapuntua da, ez suebakiko politika. Mugatu iturria benetan baimendu zenituen esleipenetara, eta eduki irteeraren sarrera-politika bereizita, tunel-trafikorako maskaratzeak zerbitzu lokalak isilean ager ez ditzan. Goiko estekako helbide dinamikoa duen ostalari batean, maskaratzeak helbidea eskuz jarraitzetik ere salbatzen zaitu.

Non aplika dezakeen zentroak eta non ez

client-to-client eta erabiltzaile-espazioko datu-bide tradizionalarekin, zentroak barne-paketeak pareen artean ematen ditu zerbitzari-prozesuaren barruan. Inoiz ez dute zentroaren kernelaren FORWARD katea zeharkatzen, beraz hango kernel-erregela batek ezin du pare arteko transiturik mugatu, hain zuzen idatzita egon arren. Betearazpena zerbitzariaren beraren politikan bizi behar da: nor sar daitekeen, zein CCD fitxategi jasotzen duen eta irteeraren jabetza lehenetsia ematen den ala ez.

Horregatik da iroute lehenetsia konfiantza-erabaki zabala. Irteerak interneteko helbide arbitrarioetatik itzulera-trafikoa zilegitasunez onartu behar du, eta zuk kontrolatzen, adabakitzen eta gainbegiratzen duzun makina bat izan behar da. Jabetza bera ematea bideratzailerik emango ez zeniokeen pare bati da diseinu honek gonbidatzen duen akatsa.

Partaidetza da benetako kontrola. Bere bideak konfigura ditzakeen edozein bezerok irteera erabiltzen saia daiteke, beraz nor sar daitekeen edo irteerak zein pare zerbitzatuko dituen mugatzea diseinuaren parte da, ez ondorengo pentsamendua.

Seguru huts egitea irteera desagertzen denean

Itzali irteera eta barneko jabetza lehenetsia haren saiokin desagertzen da. Gertatu behar ez dena zentroa isilean ordezko irteera bihurtzea da: ez bide lehenetsirik VPN igerilekutik zentroaren goiko estekara, eta ez maskaratze-erregela zabalik zentroan trafiko bera birbidaliko lukeenik. Probatu hutsegite hori nahita, eta gero probatu berreskuratzea fluxu berri batekin, jada irekita zegoen orri batekin beharrean.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Irteera joan ondoren kontsumitzailearen trafikoak oraindik internetera iristen badu, beste zerbait ari da garraiatzen eta zuk nahi zenuen muga ez da existitzen. Hartu DNS eta IPv6 erabaki bereizi gisa ere: IPv4 bide batek maskaratzearekin ez du ezer esaten AAAA trafikoaz, eta zentroak bultzatutako resolverrak galdera benetan nondik irteten den handik erantzungo du.