L'últim element de la meua llista de pendents era implementar l'opció --peer disponible a pfinet. Aquesta setmana m'he dedicat a aquesta tasca i ja la tinc acabada, de manera que puc dir que el servidor LwIP ja pot reemplaçar completament pfinet.

L'opció --peer està present en pfinet per a especificar l'adreça de l'altra part en les interfícies punt a punt, com són PPP, els túnels, etc. tot i que l'única solució punt a punt que ofereix pfinet és l'ús d'un client OpenVPN sobre un dispositiu túnel. A hores d'ara, quan s'afegeix l'opció --peer a la línia de comandes de pfinet, l'única cosa que ocorre és que aquesta adreça s'assigna a una variable interna de la interfície pertinent, però no sembla que s'estiga usant per a res. El fet és que en realitat si només estem usant un client OpenVPN sobre un túnel no necessitem que la pila sàpiga l'adreça de l'altra part, és OpenVPN qui s'encarrega d'això. Explicaré un poc per damunt com funciona tot plegat.

Suposem que la nostra organització té una aplicació web interna que només ha de ser accessible per al seu personal. En aquest cas, el servidor HTTP només servirà peticions de la xarxa 10.8.0.0/24. Per simplificar l'esquema, anem a suposar també que el servidor HTTP i el servidor OpenVPN es troben a la mateixa màquina. L'esquema quedaria així:

Com es pot veure a l'esquema, la LwIP de l'usuari treballa a tots es efectes com si es trobara a la xarxa 10.8.0.0/24, per tant, es poden configurar els seus paràmetres IPv4 amb normalitat:

settrans -fga $HOME/servers/socket/2 /hurd/lwip -6 $HOME/servers/socket/26 -i $HOME/dev/tun0 -a 10.8.0.6 -m 255.255.255.0 -g 10.8.0.1

La LwIP del sistema també està configurada amb normalitat per a eixir a Internet, de manera que no cal emprar el paràmetre --peer en cap dels dos casos. Pel que fa al túnel, el truc està en que per una banda la LwIP d'usuari li envia els paquets com si es tractara d'una targeta de xarxa més, però al mateix temps és un fitxer normal i corrent que OpenVPN pot obrir per a lectura o escriptura.

Un aspecte destacable és el següent: amb aquest disseny, l'usuari pot decidir quin trànsit viatjarà per la VPN i quin no. Per exemple, si vol descarregar un fitxer des del servidor HTTP privat ho pot fer així:

remap /servers/socket/2 $HOME/servers/socket/2 /servers/socket/26 $HOME/servers/socket/26 -- wget https://10.8.0.22/test.txt

Però si no redirigeix les RPC, el transit sortirà per la LwIP del sistema:

wget https://www.gnu.org/

I tot això sense necessitar permisos de root en cap moment.

Crec que es bon moment per a teoritzar sobre com es podria posar el marxa PPP en el Hurd. La pila actual, pfinet, no ofereix suport per a PPP, mentre que LwIP sí que ho fa però amb una API que no ens convé massa. Segons la documentació, el que LwIP ofereix és un port de pppd modificat per a ser lleuger. Si el nostre sistema fóra un dispositiu encastat, l'API que ofereix LwIP seria ideal, perquè al final en un sistema encastat el que tindríem és un únic binari que ho inclouria tot: el sistema operatiu, la pila i el nostre codi que podria cridar directament funcions com ppp_set_auth() o ppp_connect(). Però en un sistema de tipus Unix el que toca és emprar el pppd original i dotar-lo de les eines necessàries per poder comunicar-se amb la pila i crear una nova interfície pppX amb la configuració IP pertinent. Amb el meu coneixement actual sobre PPP no tinc massa clar si caldria crear operacions o inclús alguna interfície MIG nova, però em sembla un tema interessant per a poder estudiar en el futur.