Появилась задача, удаленному офису нужно подключаться к астериску, и тут и там статические «белые» IP адреса. Для решения задачи были добавлены правила:
iptables -A RH-Firewall-1-INPUT -i eth0 -s 91.211.000.000 -j ACCEPT
iptables -A RH-Firewall-1-INPUT -i eth0 -d 91.211.000.000 -j ACCEPT
если нужно открыть доступ для всех внешних подключений по SIP, то правила следующие:
iptables -A INPUT -p udp -i eth0 --dport5060-j ACCEPT
iptables -A INPUT -p tcp -i eth0 --dport5060-j ACCEPT
iptables -A INPUT -p udp -i eth0 --dport10000:20000-j ACCEPT
где eth0 интерфейс с «белым» внешним IP адресом, а 91.211.000.000 это IP адрес удаленного офиса.
Моя домашняя сеть находится в 192.168.1.0/24, а голос вынесен в подсеть 192.168.0.0/24.
доступ «в мир» роутится через 192.168.1.1 а в голос через 192.168.1.111 (да вот захотелось мне так).
Домашние машины получают ip адреса из подсети 192.168.1.0/24, а айпифоны из подсети 192.168.0.0/24
соответственно по дефолту машины не могут получить доступа к фойсовым аппаратам (ATA и IP фоны), прописывать на каждой машине статик роуты, я считаю моветоном. К счастью, не я один так считаю и есть позволяющий с DHCP сервера передавать клиентам статичные маршруты.
итак настроим dhcp сервер давать статик роут на сеть 192.168.0.0/24 через 192.168.1.111
Так как Microsoft компания новатор, срать ей хотелось на RFC. По этому в приведенном выше конфиге присутствуют ms-classless строки. Если у вас в сети нет windows машин, то можно их не уазывать.
На сервере делаем service dhcpd restart, а на клиенте /etc/init.d/networking restart и на клиенте получим:
shakirov@work:~$ route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 100 eth0
192.168.0.0 192.168.1.111 255.255.255.0 UG 000 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 100000 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 10000 eth0
справедливо это для Ubuntu на клиенте, говорят что в других дистрибутивах нужно в /etc/dhcp3/dhclient.conf добавить:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
И в том же файле в поле request добавить параметр rfc3442-classless-static-routes; выглядеть в итоге должно так:
И еще, если нет, то надо создать файл /etc/dhcp3/dhclient-exit-hooks.d/rfc3442-classless-routes
RUN="yes"
if["$RUN" = "yes"]; then if["$new_rfc3442_classless_static_routes"!= ""]; then if["$reason" = "BOUND"]||["$reason" = "REBOOT"]; then rfc_routes=($new_rfc3442_classless_static_routes)
for((i=0; i <${#rfc_routes[@]}; )); do net_length=${rfc_routes[$i]}
Today, on my 28th birthday, I'm finally delivering on a promise to my readers which I made about two months ago. I've on how to host a web application redundantly in a cloud environment. While it's still a bit of a rough draft, it should be a good starting point for those who haven't worked in virtualized environments before. Also, it may show some of the more experienced systems administrators a new way to do things.
The guide:
As always, if you find anything in the guide that needs improvement, I'm all ears.
Typical configuration for a proxy-type load balancer
A typical load balancing configuration using hardware devices or software implementations will be organized such that they resemble the diagram at the right. I usually call this a proxy-type load balancing solution since the load balancer proxies your request to some other nodes. The standard order of operations looks like this:
client makes a request
load balancer receives the request
load balancer sends request to a web node
the web server sends content back to the load balancer
the load balancer responds to the client
If you're not familiar with load balancing, here's an analogy. Consider a fast food restaurant. When you walk up to the counter and place an order, you're asking the person at the counter (the load balancer) for a hamburger. The person at the counter is going to submit your order, and then a group of people (web nodes) are going to work on it. Once your hamburger (web request) is ready, your order will be given to the person at the counter and then back to you.
This style of organization can become a problem as your web nodes begin to scale. It requires you to ensure that your load balancers can keep up with the requests and sustain higher transfer rates that come from having more web nodes serving a greater number of requests. Imagine the fast food restaurant where you have one person taking the orders but you have 30 people working on the food. The person at the counter may be able to take orders very quickly, but they may not be able to keep up with the orders coming out of the kitchen.
LVS allows for application servers to respond to clients directly
This is where really shines. LVS operates a bit differently:
client makes a request
load balancer receives the request
load balancer sends request to a web node
the web server sends the response directly to the client
The key difference is that the load balancer sends the unaltered request to the web server and the web server responds directly to the client. Here's the fast food analogy again. If you ask the person at the counter (the load balancer) for a hamburger, that person is going to take your order and give it to the kitchen staff (the web nodes) to work on it. This time around, the person at the counter is going to advise the kitchen staff that the order needs to go directly to you once it's complete. When your hamburger is ready, a member of the kitchen staff will walk to the counter and give it directly to you.
In the fast food analogy, what are the benefits? As the number of orders and kitchen staff increases, the job of the person at the counter doesn't drastically increase in difficulty. While that person will have to handle more orders and keep tabs on which of the kitchen staff is working on the least amount of orders, they don't have to worry about returning food to customers. Also, the kitchen staff doesn't need to waste time handing orders to the person at the counter. Instead, they can pass these orders directly to the customer that ordered them.
In the world of servers, this is a large benefit. Since the web servers' responses no longer pass through the load balancer, they can spend more time on what they do best — balancing traffic. This allows for smaller, lower-powered load balancing servers from the beginning. It also allows for increases in web nodes without big changes for the load balancers.
There are three main implementations of LVS to consider:
LVS-DR: Direct Routing
The load balancer receives the request and sends the packet directly to a waiting real server to process. LVS-DR has the best performance, but all of your servers must be on the same network subnet and they have to be able to share the same router (with no other routing devices in between them).
LVS-TUN: Tunneling
This is very similar to the direct routing approach, but the packets are and sent directly to the real servers once the load balancer receives them. This removes the restriction that all of the devices must be on the same network. Thanks to encapsulation, you can use this method to load balance between multiple datacenters.
LVS-NAT: Network Address Translation
Using NAT for LVS yields the least performance and scaling of all of the implementation options. In this configuration, the incoming requests are rewritten so that they will be transported correctly in a NAT environment. This puts a bigger burden on the load balancer as it must rewrite the requests quickly while still keeping up with how much work is being done by each web server.
Looking for a Linux Virtual Server HOWTO? Stay tuned. I'm preparing one for my next post.
Happy New Year! I certainly hope it's a great one for you, your family, and your business. As the new year begins, I figured it would be a good time to sit down and answer a question that I hear very often:
How do I become a better systems administrator?
The best way to become a better systems administrator is to fully understand the theory of what's happening in your server's environment.
What do I mean by that? Learn why things aren't happening as you expected and think about all of the factors that could possibly be involved. Instead of thinking purely about cause and effect, you'll find it much easier and rewarding to consider everything inside and outside your environment before you make any changes.
This still may be a little difficult to fully understand, so he's an example. Let's say you're handling an issue where a customer can't reach a website hosted on their server. When you ask them for more details, they might give you the dreaded reply: «It's not coming up.» Start by making a mental list of the problems that are easiest to check:
Is the web server daemon running?
If a database server is being used, is it running and accessible?
Is there a software/hardware firewall blocking port 80?
Is a script stuck on the server tying up resources?
Could there be a DNS resolution problem?
Is the server up?
Did a switch fail?
Is the server's hard disk out of space?
Can the customer reach other websites like Google or Yahoo?
If SELinux is involved, have the appropriate contexts been set?
Could the site be a target of a denial of service attack?
Has the server reached its connection tracking limit?
Of course, this is a relatively short list, but these are all easy to check. If you're thinking about cause and effect, you might only consider the web server daemon and some basic network issues. By considering all of the other factors that may be related, you've ensured that all of the basics are covered before you consider more complex problems.
Most systems administrators have taken an error message and tossed it in en masse into Google before. Occasionally, no results will appear for the search. If you find yourself in this situation, try to understand the individual parts of the error message. Work outward from what you know already. You should know which daemon said it, and you may have an idea of what the application was doing when the error occurred. Take time to consider what the daemon is trying to tell you within the context of what it was doing at the time.
One of the easiest ways to force yourself to be immersed into this way of thinking is to host applications for non-technical people. You'll find that many customers want things done differently, and they're all at different levels of technical aptitude. Some may find it a frustrating experience at first, but you'll think yourself later. It will force you to consider all aspects of how a server operates since you might not always know what's happening within a customer's application.
As always, if you find yourself stumbling, remember to ask your peers and colleagues. Even if they haven't seen the particular issue, they will probably be able to guide you closer to the solution you seek.
