On 10/31/16 11:48 AM, Jeff Ross wrote:
On 10/31/16 7:54 AM, Jan Stary wrote:
On Oct 30 11:28:55, jr...@openvistas.net wrote:
Hi all,
I'm moving to a new server hosted at m5 and I'm ready to pull the
trigger on
making the switch.
In the past doing this sort of move I've run into dns update
delays--even
with the ttl on my dns set to 300, there is a lot of e-mail
especially that
continues to attempt to deliver to the old server long after the dns
update
has taken place.
It seems like I should be able to use pf to redirect all inbound traffic
except ssh to the new server. I tried redirecting web traffic as a test
with the following rule in pf.conf:
#pass all non-ssl web traffic to luna
pass in quick proto tcp to port www rdr-to luna.openvistas.net port 80
but that doesn't work--the connection never completes. httpd is for
sure
working on the new server--I've been using an /etc/hosts file to test
from
my home Mac and the web sites all work fine.
The rule references the name.
Are you sure it resolves to the new address already?
Would it be safer to just hardcode the IP address for the transition?
Also, this is probably not your _entire_ pf.conf
For example, there is no rule letting the redirected packet out.
Jan
Yes, the domain name resolves.
I followed the example that Philipp pointed me toward and that fixed the
issue of redirecting web traffic.
Thanks for the reply!
Jeff
Update:
I found a tutorial on relayd on calomel.org that helped me better
understand relayd. I know full what what the openbsd community thinks
(and rightfully so most of the time) about these sorts of articles and
how fast they become outdated and worthless but this one helped me
better understand relayd.
https://calomel.org/relayd.html
Based on that, I saw that I needed a very simple TCP port relay. This
relayd.conf file redirected all web traffic from my existing server to
the new server hosted at m5:
## Macros
#
varley_addr="64.85.162.217"
luna_addr="207.158.15.155"
www="80"
## TCP port relay and forwarder
#
protocol "tcp_service" {
tcp { nodelay, socket buffer 65536 }
}
relay "www_forwarder" {
listen on $varley_addr port $www
protocol "tcp_service"
forward to $luna_addr port $www
}
I will also note that the relayd.conf man page also has all of this
information--see the second relay example--and now that I better
understand relayd as a whole the rest of the man page makes more sense
as well.
I've further extended my initial configuration to include smtp, smtps,
submission and imaps with this configuration:
prefork 10
## Macros
#
varley_addr="64.85.162.217"
luna_addr="207.158.15.155"
www="80"
smtp="25"
imaps="993"
smtps="465"
submission="587"
## TCP port relay and forwarder
#
protocol "tcp_service" {
tcp { nodelay, socket buffer 65536 }
}
relay "www_forwarder" {
listen on $varley_addr port $www
protocol "tcp_service"
forward to $luna_addr port $www
}
relay "smtp_forwarder" {
listen on $varley_addr port $smtp
protocol "tcp_service"
forward to $luna_addr port $smtp
}
relay "imaps_forwarder" {
listen on $varley_addr port $imaps
protocol "tcp_service"
forward to $luna_addr port $imaps
}
relay "smtps_forwarder" {
listen on $varley_addr port $smtps
protocol "tcp_service"
forward to $luna_addr port $smtps
}
relay "submission_forwarder" {
listen on $varley_addr port $submission
protocol "tcp_service"
forward to $luna_addr port $submission
}
relayd -n -f /etc/relayd.conf says the configuration is OK so after peak
business hours for my clients I'll turn on relayd and see what happens.
If you are familiar with relayd and see something wrong with my
configuration, please chime in. I'll report success and any possible
glitches I run across for the archives.
Thanks for your help and for reading!
Jeff Ross
