0

I have been testing keepalived and preparing to roll out on my vps.

My setup is:

(...)
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel  state UP group default qlen 1000
    link/ether ab:cd:ef:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.xxx/24 brd xxx.xxx.xxx.xxx scope global ens4
       valid_lft forever preferred_lft forever
    inet 192.168.1.2/24 scope global ens4:1
       valid_lft forever preferred_lft forever
    inet 192.168.1.3/24 scope global secondary ens4:2
       valid_lft forever preferred_lft forever

192.168.1.2 is the private IP address "looking" into private network (assigned by my hosting provider) 192.168.1.3 is the floating IP, also on private network (assigned by my hosting provider)

I have a separate host, 192.168.1.99, which I would like to route traffic through my floating IP. So on keepalived, when host is becoming master, I am adding those routes:

ip route add 192.168.1.3/32 via 192.168.1.3 dev ens4 src 192.168.1.3
ip route add 192.168.1.99/32 via 192.168.1.3 dev ens4 src 192.168.1.3

And everything works great, when I ping 192.168.1.99 and running tcp dump on that host I can see traffic is being routed correctly.

My problem is that I'm running postgresql on that host with floating IP which I would like to be only available through 192.168.1.3 (not even through 127.0.0.1). And it works great as long as database is accessed from the outside. When I try to make connection from 192.168.1.3 via 192.168.1.3 I get an error:

FATAL:  no pg_hba.conf entry for host "192.168.1.2", user "postgres", database "postgres", SSL off

This tells me that my routing is not working when exercising it from the keepalived host itself.

I'm wondering how do I modify my routing so traffic goes through 192.168.1.3 even when originating from that same host.

Greg0ry
  • 107
  • 1
  • 12

1 Answers1

1

You have access deny error which means that the routing works well.

Routing doesn't change source or destination ip addresses in ip packets. Use firewall to disallow access to postgres database on 192.168.1.2 ip address. When postgress client connect to your server's 192.168.1.3 ip address it use first ip address 192.168.1.2 on server's interface. This address doesn't allowed in pg_hba.conf config file.

Also this network scenario isn't good because postgres and other software will answer from first ip address (which are in one network) on ens4 interface.

You don't need to add such routing rules, because all ip address in them are in one network 192.168.1.0/24.

Mikhail Khirgiy
  • 2,073
  • 11
  • 7
  • This is what question is about, I don't want this traffic to come through the interface alias it came through. If you read the question you will notice, I want the traffic to come through `192.168.1.3`, not `192.168.1.2`. – Greg0ry Apr 26 '17 at 08:32
  • Use one ip address on interface and firewall to allow or disallow access to your server. – Mikhail Khirgiy Apr 26 '17 at 08:52
  • If you read my question you will notice I have three aliases due to my VPS provider. One for public connections, one for private inter-VPS connections and one which is a floating IP. This is not something I have control to change. – Greg0ry Apr 26 '17 at 09:52
  • All software will connect to services in `192.168.1.0/24` network with source ip `192.168.1.2` because it's first ip address in this network on server's interface. Routing doesn't help you. – Mikhail Khirgiy Apr 26 '17 at 15:53
  • I'm not sure what your comment relates to, you can add metric to routes and route with lower metric will be used as prefered route. You make lots of bold statements which have no common point with my question. First statement about `access deny` is plain wrong, log clearly says what the source is. Second statement is wrong since if your routing results in OS picking certain interface then result will be the changed source IP. And third statement is wrong since postgres will answer on interface it was bound to with `listen_addresses`. Thanks anyways. – Greg0ry Apr 26 '17 at 21:59
  • @Gregory, you are wrong. Only firewall NAT operation can change source or destination ip addresses. Routing can't do it. – Mikhail Khirgiy Apr 27 '17 at 04:22
  • @Greg0ry What do you mean by "come through 192.168.1.3" exactly? Do you mean be received on the interface that's assigned that IP address? Because, if so, that clearly can't mean anything when the traffic originates locally. – David Schwartz Apr 27 '17 at 04:26
  • Ok, I'm confused. How will linux kernel make decision which interface to select if not by using default route? If I have two interfaces connected to two separate networks then will the traffic not be routed through interface with default route with lower metric? – Greg0ry Apr 27 '17 at 17:46
  • @DavidSchwartz - I mean outbound traffic. My postgres is bound to `192.168.1.3` (so it listens on that address and that works ok) but I also would like it to send traffic out through that same interface. So I thought I can configure default route with low metric and traffic would go through that interface does this not make sense? – Greg0ry Apr 27 '17 at 17:48
  • 1
    @Greg0ry It will send traffic out on the interface that has the route to the next hop. Are you saying it's not doing that? – David Schwartz Apr 27 '17 at 19:27
  • @DavidSchwartz - so I have two interfaces facing the same network and indeed it seems no matter what default route I set kernel won't pick the interface I prefer. I need to read more about routing and how kernel selects interface if more than one face the same network. – Greg0ry May 02 '17 at 15:05
  • @MikhailKhirgiy - thanks for suggestion, now I understand what you was saying and my misunderstanding of subject led me to conclusion my question was misunderstood. Quite oposite. Thanks for your suggestion, I'll explore more on it. – Greg0ry May 02 '17 at 15:06
  • @MikhailKhirgiy - but there is one question that comes to my head - why the routing through second interface works well when pinging other servers in that same network? tcpdump tells me the traffic comes through correct interface. Why would this work different when performing communication to local interface? – Greg0ry May 02 '17 at 15:09
  • And last comment - I'll accept your answer since with your comments about firewall nat rules it points to solution to my problem though I'll go for simpler option and just add all my local interfaces to pg_hba.conf. – Greg0ry May 02 '17 at 15:12
  • @Gregory You have only one interface `ens4`. Other interfaces `ens4:1` and `ens4:2` are only synonyms of `ens4` interface. You have 3 ip addresses on one interface. You can see all interfaces by command `cat /proc/net/dev`. – Mikhail Khirgiy May 02 '17 at 16:56
  • @MikhailKhirgiy - I just found this answer which mentiones static routes. In light of what you said (and what I observed) static routes should not do what people in that post are saying it woul do? https://unix.stackexchange.com/questions/243451/iptables-change-local-source-address-if-destination-address-matches – Greg0ry May 11 '17 at 21:46
  • @MikhailKhirgiy I'm trying to write iptables forwarding rule that would ensure all traffic destined to certain IP always originates through my selected alias. I have added those three rules: `iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE`, `iptables -A FORWARD -i ens4 --source 192.168.203.47/32 -o 192.168.129.111 -m state --state RELATED,ESTABLISHED -j ACCEPT` and `iptables -A FORWARD -i ens4 --source 192.168.203.47/32 -o 192.168.129.111 -j ACCEPT` but it does not seem to be resulting in changed source IP, can you advice? – Greg0ry May 11 '17 at 22:23