I am having a hard time trying to get the authentication working from Nginx through a Haproxy for load balancing. I had the configurations written for haproxy.cfg and nginx.conf as shown below respectively. The Haproxy is in front of my nginx server. I was able to get a prompt for username and password when I hit the haproxy server, however when hit enter after filling up the username and password, it returns "403 Forbidden" as a response on the web page.
Does anyone know what could be the correct configuration settings for the haproxy.cfg? Or perhaps a solution? Thanks in advance!!
HAPROXY.cfg
global
daemon
maxconn 256
defaults
mode tcp
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
frontend http-in
bind *:80
default_backend servers
backend servers
balance roundrobin
server server1 http://mynginx.test.com:9090 maxconn 32
NGINX.conf
location /myapp {
auth_gss on;
auth_gss_allow_basic_fallback off
auth_gss_keytab /etc/krb5.keytab
proxy_pass http://192.168.1.100:8080/link/;
}
Found the solution. The reason for the 403 forbidden error is because of my keytab. I need to regenerate a new one use by the haproxy instead of nginx. However, I'm getting 'Access-Control-Allow-Origin'. Could anybody enlighten?
Related
I am using NGINX as load balancer for Apache WebServers (WordPress). All servers are made with AWS EC2. My config for NGINX:
cat /etc/nginx/sites-available/default
upstream web_backend {
server 35.157.101.5;
server 35.156.213.23;
}
server {
listen 80;
location / {
proxy_pass http://web_backend;
}
}
But after NGINX restart i am access load balancer via public ip and getting an error:
Bad Request
Your browser sent a request that this server could not understand.
Additionally, a 400 Bad Request error was encountered while trying to
use an ErrorDocument to handle the request.
Apache/2.4.29 (Ubuntu) Server at
ip-172-31-35-36.eu-central-1.compute.internal Port 80
If i refresh page i am getting same error but with another ip in the end (second server’s private ip), so i understand that NGINX do the work and it is Apache problem.
I tried to add 80 port for my servers in nginx config, replace ips with dns and private ip, but it didn’t help. Access log on Apache doesn’t show anything useful, just 400 errors.
What could be the problem?
Don’t use ‘_’ for upstream name, it was the only reason for my problem.
Just check on which ports are the Apache WebServers Running. You have to add those to your upstreams.
E.g.:
upstream web_backend {
server 35.157.101.5:8080; //assuming that your apache webserver is running on this port on this host
server 35.156.213.23:3000;//And a different port on the other.. you still need to add them here if your ports are same
}
I am trying to get the equivalent of the nginx passtrough where a user would see my website url in the address bar but get all the content to be proxied from another website.
At the moment the code below redirects the user to example2 by returning a 304, instead of proxying the traffic.
I need it to work with http (not tcp) because I need this as part of an AB test where I need to inspect the cookies. Please check the comments on the code below for what I am trying to do.
defaults
mode http
log global
option httplog
log 127.0.0.1 local0
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
listen http
bind 127.0.0.1:8080
acl set_cookie path_beg /set-cookie
use_backend b-backend if { req.cook(SITEID) -m beg b-backend }
use_backend b-backend if set_cookie
default_backend ab-split-backend
backend a-backend
option forwardfor
server example1 example1.com:443 check maxconn 3000 inter 30s
backend b-backend
cookie SITEID insert
option http_proxy
# how do I get example2 to passtrough and not 304 redirect?
server example2 example2.com:443 check maxconn 3000 inter 30s
backend ab-split-backend
balance roundrobin
cookie SITEID insert indirect nocache maxlife 48h
# how do I get example2 to passtrough?
server example2 example2.com:443 weight 50 cookie b-backend
server example1 example1.com:443 weight 50 cookie a-backend
HTTP 304 is not really a redirect, it is an empty response indicating Not Modified which tells the client that the server would have responded with a 200 and served the content, but the requested asset has not changed, so the client can just use what it has cached.
So I'm not entirely sure what you're seeing is incorrect behavior. That is, your requests may be being passed through just fine, and the backend server may be correctly responding with a 304.
The server makes the decision to respond with this code based on information provided in the request headers If-Modified-Since and/or If-None-Match. So if you really want to disable this caching mechanism and ensure a complete 200 response every time, you can instruct HAProxy to delete these headers from the incoming request:
listen http
bind 127.0.0.1:8080
acl set_cookie path_beg /set-cookie
# Delete headers related to caching
http-request del-header If-Modified-Since
http-request del-header If-None-Match
use_backend b-backend if { req.cook(SITEID) -m beg b-backend }
use_backend b-backend if set_cookie
default_backend ab-split-backend
it looks like what you are trying to do is keep your system from trying to pass it through via SSL and instead do clear text based assessments for testing purposes. I would recommend seeing a snippet from my config below on http-request redirects and also look into HAProxy schemes. I would also recommend seeing the additional example for instance based redirection, specifically for a dictated location, that way you dont unencrypt traffic accidentally that you want to remain encrypted.
As for the information proxied from another location, your best bet for that would be with using Cloudflare, especially if you are looking for some form of DDoS/additional layers of security. The alternative is building your own custom anti-DDoS Solution, which is a major pain.
frontend ALL
bind *:80
bind *:443 alpn h2,http/1.1 ssl crt /etc/haproxy/certs/eduarmor.com.pem
http-request redirect scheme https code 301 if !{ ssl_fc }
http-request redirect code 301 location http://www.%[hdr(host)]%[capture.req.uri] if { hdr(Host) -i eduarmor.com }
mode http
I'm trying to monitor a VHost on the local Apache instance via Monit. The same domain accepts both http and https traffic, so I wanted to monitor both.
Also, the IP that the domain resolves to goes to a server that load balances the traffic between the current Apache instance and another server running Apache. I need Monit to monitor the local instance, and I was hoping to avoid adding any records in the /etc/hosts file, so I was thinking that Monits config setting with http headers [] would suffice, and I think it is (Just monitoring localhost, but setting the headers Host to the vhost domain).
Anyways, the main problem I seem to be running into, is even though I configure Monit to monitor the host via both http and https protocols, it monitors both hosts via just http, however the port is set to 443 for the one I need using https protocol.
The Monit config file for Apache is:
check process httpd with pidfile /var/run/httpd/httpd.pid
start program = "/bin/systemctl restart httpd.service" with timeout 60 seconds
stop program = "/bin/systemctl stop httpd.service"
check host localhost with address localhost
if failed
port 80
protocol http
with http headers [Host: www.domain.com, Cache-Control: no-cache]
and request / with content = "www.domain.com"
then restart
if failed
port 443
protocol https
with http headers [Host: www.domain.com, Cache-Control: no-cache]
and request / with content = "www.domain.com"
then restart
if 5 restarts within 5 cycles
then timeout
And here's the Monit status for that check:
[root#server enabled-monitors]# monit status localhost
The Monit daemon 5.14 uptime: 14m
Remote Host 'localhost'
status Connection failed
monitoring status Monitored
port response time FAILED to [localhost]:443/ type TCPSSL/IP protocol HTTP
port response time 0.001s to [localhost]:80/ type TCP/IP protocol HTTP
data collected Tue, 26 Apr 2016 10:44:32
So it's fairly obvious to me that the https is failing because its still trying to use port HTTP, even though I have protocol https in the configuration.
Any input would be much appreciated. I have a feeling this may be a bug, and ill create an issue in the Monit Github repo, but I wan't to make sure it's not something silly that I overlooked.
Thank you!
Late reply here, but I thought I would still post for readers who stumbled upon the same issue.
The problem seems to be not with Monit using port HTTP despite check configured for HTTPS. It always reports HTTP protocol in status (a display bug).
The real issue is likely with Monit not supporting SNI for SSL, so it ignores the with http headers [Host: www.domain.com ... in your https check. Thus the check fails because Monit is actually testing https://localhost.
I've filed bug with Monit developers here.
In order to test every possible solution to get Socket.io working with a parallel Apache installation, I have now installed HAproxy that listens on port 80. It proxies everything to Apache, unless the hostname equals io.server.com.
We have two IPs connected to our server: 1 is for SSL, the other for all the NON-SSL subdomains we have. I have created the io.server.com subdomain to point to that NON-SSL IP-address. However, the following this occurs:
A visit to regular_http.server.com results in Apache handling that sub domain (OK)
A visit to io.server.com results in "Welcome to Socket.io" (OK)
Next visit to regular_http.example.com results in "Welcome to Socket.io"
Why is HAproxy sending requests from a subdomain not configured to go to Socket.io, to Socket.io ?
Yes, the two sub domains share the IP, but is HAproxy really proxying the whole IP under one? What is then the point with setting up ACLs based on host name?
Here's my configuration:
global
daemon
maxconn 4096
user haproxy
group haproxy
defaults
log global
#this frontend interface receives the incoming http requests
frontend http-in
mode http
bind *:80
timeout client 86400000
#default behavior sends the requests to apache
default_backend www_backend
#when "io.test.tld" is matched, an acl I call arbitrarily
# "websocket" triggers
acl websocket hdr_end(host) -i io.server.com
use_backend node_backend if websocket
Thank you!
This problem was solved using the option http-server-close configuration value in HAproxy.
I have configured haproxy to redirect the path "/rawman" to port 8080 on my server. It works the first time, but as soon as I visit the default site it stops working. The default site is running on apache with mod_rewrite and it is catching invalid requests (using codeigniter) so instead of seeing the redirected site when I visit http://mysite.com/rawman?foo=bar I see the default site.
This is my haproxy config:
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
user haproxy
group haproxy
daemon
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 50000
srvtimeout 50000
frontend http_proxy
bind 0.0.0.0:8090
acl is_ast path_beg /rawman
use_backend ast if is_ast
default_backend mysite
backend ast
server ast 0.0.0.0:8080
backend mysite
server local 0.0.0.0:80
Try setting option httpclose after the srvtimeout line.
If you don't do that then haproxy uses the target server's keepalive setting. Once you visit the main site the connection is opened and kept open, and on your next request haproxy goes oh isn't that nice: I have an open connection. Lets just use it even though it shouldn't. With the httpclose option set it always closes the connection, ensuring that each new request uses the right connection.
Lost 3 hours of my life figuring that out.