TL;DR: En Mojave (no he probado en otros), a la hora de crear rdr normas pf, las reglas de trabajo por un tiempo (con algunos problemas de acceso al puerto de destino directamente), pero después de un tiempo las reglas de dejar de trabajar, aunque yo no puedo hacer pfctl informe de cualquier cosa de manera diferente en una manera que hace que sea evidente que ya no se aplican.
He creado /Library/LaunchDaemons/dev.up.pfctl.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Disabled</key>
<false/>
<key>Label</key>
<string>dev.up.pfctl</string>
<key>WorkingDirectory</key>
<string>/var/run</string>
<key>Program</key>
<string>/sbin/pfctl</string>
<key>ProgramArguments</key>
<array>
<string>pfctl</string>
<string>-e</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
...y /Library/LaunchDaemons/dev.up.loopbackalias.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>dev.up.loopbackalias.plist</string>
<key>RunAtLoad</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/sbin/ifconfig</string>
<string>lo0</string>
<string>alias</string>
<string>127.0.0.42</string>
</array>
</dict>
</plist>
He añadido lo siguiente a /etc/pf.conf:
# allow nginx to bind on :20080 instead of :80, and :20443 instead of :443.
# This allows us to run it as the non-root user, and thus not require
# auth to update/restart it.
rdr pass on lo0 inet proto tcp from any to 127.0.0.42 port 80 -> 127.0.0.42 port 20080
rdr pass on lo0 inet proto tcp from any to 127.0.0.42 port 443 -> 127.0.0.42 port 20443
...y me he nginx ejecución y obligado a 127.0.0.42:20080 y 127.0.0.42:20443.
Cuando voy a aplicar la configuración al reiniciar o ejecución pfctl -f /etc/pf.conf, las cosas funcionan:
$ curl http://127.0.0.42:80/services/ping
ok
Sin embargo...
Problema 1
Mientras que esta regla está activa, el acceso al puerto de destino (20080/20443) directamente tiene algunos problemas interesantes. Hay un retraso en el acceso a lo que parece crecer rápidamente con el número de la (reciente?) accesos:
$ time curl -s -o /dev/null http://127.0.0.42:20080/services/ping
(0.2 seconds)
$ time curl -s -o /dev/null http://127.0.0.42:20080/services/ping
(1.6 seconds)
$ time curl -s -o /dev/null http://127.0.0.42:20080/services/ping
(27 seconds)
$ time curl -s -o /dev/null http://127.0.0.42:20080/services/ping
(timeout)
(sin embargo, el recinto del hotel, el acceso a :80-el puerto redirige pf a :20080-trabajos y tarda <25ms.)
Problema 2
Después de un tiempo, la redirección de la regla se detiene por completo la aplicación, como si pf no se han habilitado en todos o la regla no cargan, sin embargo, que sigue pretende ser habilitado y sigo sin ver lo reportado por pf:
$ pfctl -s nat
No ALTQ support in kernel
ALTQ related functions disabled
nat-anchor "com.apple/*" all
rdr-anchor "com.apple/*" all
rdr pass on lo0 inet proto tcp from any to 127.0.0.42 port = 80 -> 127.0.0.42 port 20080
rdr pass on lo0 inet proto tcp from any to 127.0.0.42 port = 443 -> 127.0.0.42 port 20443
$ pfctl -s info | grep Enabled
No ALTQ support in kernel
ALTQ related functions disabled
Status: Enabled for 6 days 14:56:42 Debug: Urgent
$ curl -s http://127.0.0.42:80/services/ping
curl: (7) Failed to connect to 127.0.0.42 port 80: Connection refused
$ curl -s http://127.0.0.42:20080/services/ping
ok
Soy capaz de desencadenar esta bastante fiable por la desconexión de WiFi. Creo probable que esto sólo ocurre cuando los cambios en la red suceder.
