The secret of an unused xl0 or get control over your network
As you all remember, at the end of the previous post I promised to consider in more detail the following questions in brief and as accessible as possible :
1. Setting up DHCP
2. Raise your DNS to a minimum
3. Removal of statistics on interfaces using snmp and drawing beauty in cacti
4. Limiting traffic on users within the network
5. Maintain detailed statistics on how and where traffic is spent
6. Setting up backup channels in the case of another provider (and forgot about xl0)
7. Route traffic between multiple channels using ipfw
In light of the previous discussions, I would like to remind you:
- articles from the “FreeBSD for dummies” series
- no, I will not write about pf and altq
- calm down with hard-drive solutions and proxy on Windows - it’s not about them
- no, not a word about squid & sarg - not our method, although no one forbade it?
- 10.10.10.0/24 and 172.16.0.0/24 because not 123.123.123.122 and not 222.222.222.222 does not hurt my eyes
- it is impossible to do this and is not recommended - this is not a guide, it is just a demonstration of the concept in general. Ideally, there should not be any allow access to mysql under the root, and so on. Well, you understand :)
So let's go in order
')
We check for a start with our beautiful spherical network in a vacuum and decide that it would be nice to distribute network settings (aipishka, mask, gateway, dns-s) to everyone
Installing isc-dhcpd should not cause any difficulties:
Then add the following to /etc/rc.conf:
Next, edit our /usr/local/etc/dhcpd.conf as follows:
Why so perverted? And in order to make it easier to add hosts to the sabnet automatically, avoiding messing around with the “}”
Let's go now to watch what will be our subnet to be:
/usr/local/etc/dhcp_subnets.conf
and for the test we drive the following:
Everything seems to be trying to start this whole thing.
Oppanki - started. OK.
As you can see from the options option domain-name-servers 192.168.0.1 now we will be using an accelerated program to raise our DNS server. We will have it only forwarding, because for the time being we have fully relied on the impeccability of our provider. And we will not keep our zones yet. We will simply hand out the Internet to Natalya Vasilyevna and Grigory Sergeyevich. Even on two providers we will rely.
Why two?
SUDDENLY a second provider appears, faster and cheaper. And we are not going to give up the old so - why should the good be lost? We will use it as a backup link.
We look /etc/namedb/named.conf
We rasskazimenyvaem
Begin to listen to our internal fxp0
Uncommenting forwarders that will look like 10.10.10.2 and 172.16.0.2 (yes yes - the second provider already lives on the xl0 network card on which the ipish hangs 172.16.0.1)
We save and try to run:
Testim launched at least:
It seems to start
Does it work?
Works! Excellent.
We write a line in /etc/rc.conf
fix in /etc/resolv.conf
on
As already mentioned, we have another provider that we would like to use as the main one?
We open our suffering /etc/firewall.conf and in the place where we all have to do things like this:
Well, raise the second natd for the new provider:
Let's briefly review how it works so that in the future we will not be confused:
• Rule 1799 is a direct inbound traffic from our network from plate 2 in natd
• Rule 1800 is similar to the previous one, but already for the backup channel and naturally nothing will get in there as long as there is 1799
• Rules 1847 are intended only for prokidydka we need the host on which we will monitor the liveliness of the channel through the new provider (172.16.0.2)
• Rules 1849 and 1850 are tough to tell what to do with the traffic that appeared on the corresponding network card
• Well, 2099 and 2100, respectively, reverse diverts in natd
The logic of the work is simple - if the rules 1799, 1849, 2099 are alive, the Internet goes by a new provider who 172.16.0.2 if they are absent the traffic “unexpectedly” rushes in 10.10.10.2 =)
We'll write such a switch later.
We look that went the following point of our program for today. Oh ... snmp and install apache + mysql + php + cacti ... Can we postpone the next time? Well, please — ah! Well, at least the installation and configuration of cacti. Let's now put the billing, and we will be in the finals to monitor and finish the beauty?
Agreed? ;) Then let's go.
For such microtasks we will use open source billing stargazer which is the simplest and most predictable solution I have seen so far.
To install it we need:
1. mysql in which we will store billing data
2. since slender crutches and supports we will write in php we will install php + apache
3. actually the last stable stargazer
To begin with, I recommend knowing at least with such a minimum dock or with other dedicated to installing the apache + php + mysql bundles. I will describe in brief.
Let's go to put mysql.
We start to put php
And we collect extensions of support for mysql, gd, iconv and what else we might need in the future.
We are trying to establish everything as we would like to:
Well, actually check whether everything turned out as I wanted to go to the browser at 192.168.0.1/test.php
Fine. Now we start to put something for which all this was started:
Now we will convert the default text database to mysql. Rules convertor.conf:
Commenting on store_postgresql:
Breaking open and converting to the required type store_mysql:
We try to convert:
An empty base is instantly converted. We are starting to configure stargazer.
We register traffic classes
Fiddle under the realities of life config:
At least we rule the names of the directions:
We build the cap_bpf traffic capture module so that it considers it on the interface looking into the internal network
We comment on everything related to <StoreModule store_files> and, by analogy with the converter, we connect the <StoreModule store_mysql> module:
We try to run the stargazer itself:
And check how they started
If we see something similar to Stg started successfully. So there is a chance for life;)
We load windows configurator at stg.dp.ua/download/sgconfig/1.91.9/sgconfig.1.91.9.win.exe and after installation in the settings we set the connection to 192.168.0.1.
The default login / password is admin / 123456. After login, we should see something like
With the default test user here, feel free to delete.
Change the admin password, or add new ones. We add, on the basis of the old scheme for the test, our Maria Ivanovna from accounting with aipishka 192.168.0.2
It will be “always Online” with us because there is no need in the office environment to use auth_ia requiring you to specify a login / password to access the network.
In the fields UserData0 and UserData1 we drive in speed and MAC and that’s why:
The logic of the stargazer is very simple and flexible. When the user appears online, the following scripts are disconnected, deleted and added:
The purpose of which is easy to guess by their names. They are all located in / etc / stargazer /
We start to beat them under our realities
To begin with, we create another 2 scripts for PHP (not for nothing, we put it;) with the help of which we will get the speed and MAC of the user from the database.
Script / etc / stargazer / GetSpeed ​​with content
And / etc / stargazer / GetMac view
We assign them the rights to perform
Testing them on the topic of health for a previously created user:
Fine!
We start to think what will happen when the user appears online and falls offline.
So, what will happen when a user appears online:
and what will happen if it falls out of the online:
I think everything is clear here - we just raise / delete the corresponding shaping rules for the user's ID and make it allow further than our local fxp0 interface.
I remember from the beginning, they were not limited to anything, because at the very end stood allow ip from any to any? No problems.
Add something like to /etc/firewall.conf
Now we try to enable / disable "always Online" for our experimental user and look at /var/stargazer/allconnect.log
Mistress note : it is always useful to control by eye what and how it goes and according to what rules with
All - in the minimum version of the billing delivered. You ask, why should we count money? It's very simple - we wanted our Marivanovna to give out no more than 500 meg Internet per month or simply to give her a certain speed with a certain amount of traffic to her manually as needed? No problems. Just equate 1 meg to one denyuzhke for ease of calculation. Suppose so
In general, there is room for creativity.
In my opinion, the article turned out to be some kind of extremely long and gloomy. Clearly it's time to get round.
Next time, if karma allows me to promise to tell you how to make a switch to the backup channel, draw such beautiful graphics with cacti
and how convenient it is to arrange the display of statistics on the traffic collected by the stargazer we set today.
Threat and yes - my Russian unlearned at school since the previous time has not regrettably not improved :(
1. Setting up DHCP
2. Raise your DNS to a minimum
3. Removal of statistics on interfaces using snmp and drawing beauty in cacti
4. Limiting traffic on users within the network
5. Maintain detailed statistics on how and where traffic is spent
6. Setting up backup channels in the case of another provider (and forgot about xl0)
7. Route traffic between multiple channels using ipfw
In light of the previous discussions, I would like to remind you:
- articles from the “FreeBSD for dummies” series
- no, I will not write about pf and altq
- calm down with hard-drive solutions and proxy on Windows - it’s not about them
- no, not a word about squid & sarg - not our method, although no one forbade it?
- 10.10.10.0/24 and 172.16.0.0/24 because not 123.123.123.122 and not 222.222.222.222 does not hurt my eyes
- it is impossible to do this and is not recommended - this is not a guide, it is just a demonstration of the concept in general. Ideally, there should not be any allow access to mysql under the root, and so on. Well, you understand :)
So let's go in order
')
We check for a start with our beautiful spherical network in a vacuum and decide that it would be nice to distribute network settings (aipishka, mask, gateway, dns-s) to everyone
Installing isc-dhcpd should not cause any difficulties:
#cd /usr/ports/net/isc-dhcp40-server/
#make install
Then add the following to /etc/rc.conf:
dhcpd_enable="YES"
dhcpd_flags="-q"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="fxp0"
Next, edit our /usr/local/etc/dhcpd.conf as follows:
option domain-name-servers 192.168.0.1;
default-lease-time 3600;
max-lease-time 43200;
authoritative;
ddns-update-style none;
log-facility local7;
one-lease-per-client true;
deny duplicates;
subnet 192.168.0.0 netmask 255.255.255.0 {
default-lease-time 3600;
option domain-name "office";
option subnet-mask 255.255.255.0;
option routers 192.168.0.1;
include "/usr/local/etc/dhcp_subnets.conf";
}
Why so perverted? And in order to make it easier to add hosts to the sabnet automatically, avoiding messing around with the “}”
Let's go now to watch what will be our subnet to be:
/usr/local/etc/dhcp_subnets.conf
and for the test we drive the following:
host hostmariya {
hardware ethernet 00:a1:b0:01:bc:77;
fixed-address 192.168.0.2;
}
Everything seems to be trying to start this whole thing.
# /usr/local/etc/rc.d/isc-dhcpd start
Oppanki - started. OK.
As you can see from the options option domain-name-servers 192.168.0.1 now we will be using an accelerated program to raise our DNS server. We will have it only forwarding, because for the time being we have fully relied on the impeccability of our provider. And we will not keep our zones yet. We will simply hand out the Internet to Natalya Vasilyevna and Grigory Sergeyevich. Even on two providers we will rely.
Why two?
SUDDENLY a second provider appears, faster and cheaper. And we are not going to give up the old so - why should the good be lost? We will use it as a backup link.
We look /etc/namedb/named.conf
We rasskazimenyvaem
forward only;
Begin to listen to our internal fxp0
listen-on { 127.0.0.1; 192.168.0.1; };
Uncommenting forwarders that will look like 10.10.10.2 and 172.16.0.2 (yes yes - the second provider already lives on the xl0 network card on which the ipish hangs 172.16.0.1)
forwarders {
10.10.10.2;
172.16.0.1;
};
We save and try to run:
#/usr/sbin/named -t /var/named -u bind
Testim launched at least:
#ps aux | grep named
bind 10095 0.0 0.7 4280 3484 ?? Ss 7:58PM 0:00.11 /usr/sbin/named -t /var/named -u bind
It seems to start
Does it work?
# nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: google.com
Address: 74.125.127.100
Name: google.com
Address: 74.125.45.100
Name: google.com
Address: 74.125.67.100
Works! Excellent.
We write a line in /etc/rc.conf
named_enable="YES"
fix in /etc/resolv.conf
on
nameserver 127.0.0.1
As already mentioned, we have another provider that we would like to use as the main one?
We open our suffering /etc/firewall.conf and in the place where we all have to do things like this:
#internet natting and preserving
${FwCMD} add 1799 divert 8671 ip from table\(2\) to not table\(9\)
${FwCMD} add 1800 divert 8672 ip from table\(2\) to not table\(9\) out via xl0
${FwCMD} add 1847 fwd 172.16.0.2 ip from me to 213.180.204.8
${FwCMD} add 1849 fwd 10.10.10.2 ip from 10.10.10.1 to not table\(9\)
${FwCMD} add 1850 fwd 172.16.0.2 ip from 172.16.0.1 to not table\(9\)
${FwCMD} add 2099 divert 8671 ip from any to 10.10.10.1 in via rl0
${FwCMD} add 2100 divert 8672 ip from any to 172.16.0.1 in via xl0
Well, raise the second natd for the new provider:
/sbin/natd -u -p 8672 -a 172.16.0.1
Let's briefly review how it works so that in the future we will not be confused:
• Rule 1799 is a direct inbound traffic from our network from plate 2 in natd
• Rule 1800 is similar to the previous one, but already for the backup channel and naturally nothing will get in there as long as there is 1799
• Rules 1847 are intended only for prokidydka we need the host on which we will monitor the liveliness of the channel through the new provider (172.16.0.2)
• Rules 1849 and 1850 are tough to tell what to do with the traffic that appeared on the corresponding network card
• Well, 2099 and 2100, respectively, reverse diverts in natd
The logic of the work is simple - if the rules 1799, 1849, 2099 are alive, the Internet goes by a new provider who 172.16.0.2 if they are absent the traffic “unexpectedly” rushes in 10.10.10.2 =)
We'll write such a switch later.
We look that went the following point of our program for today. Oh ... snmp and install apache + mysql + php + cacti ... Can we postpone the next time? Well, please — ah! Well, at least the installation and configuration of cacti. Let's now put the billing, and we will be in the finals to monitor and finish the beauty?
Agreed? ;) Then let's go.
For such microtasks we will use open source billing stargazer which is the simplest and most predictable solution I have seen so far.
To install it we need:
1. mysql in which we will store billing data
2. since slender crutches and supports we will write in php we will install php + apache
3. actually the last stable stargazer
To begin with, I recommend knowing at least with such a minimum dock or with other dedicated to installing the apache + php + mysql bundles. I will describe in brief.
Let's go to put mysql.
# cd /usr/ports/databases/mysql50-server/
# make install
# /usr/local/bin/mysqladmin -u root -p password ourpassword
We start to put php
# cd /usr/ports/lang/php5/
# make install
And we collect extensions of support for mysql, gd, iconv and what else we might need in the future.
# cd /usr/ports/lang/php5-extensions
# make install
We are trying to establish everything as we would like to:
# apachectl start
# echo "<?php phpinfo(); ?>" > /usr/local/www/data/test.php
Well, actually check whether everything turned out as I wanted to go to the browser at 192.168.0.1/test.php
Fine. Now we start to put something for which all this was started:
# fetch www.stg.dp.ua/download/server/2.406/stg-2.406.src.tgz
# tar zxvf stg-2.406.src.tgz
# cd stg-2.406
# cd projects/stargazer/
# ./build
#gmake install
#cd ../convertor/
#./build
Now we will convert the default text database to mysql. Rules convertor.conf:
Commenting on store_postgresql:
#<DestStoreModule store_postgresql>
# server = localhost
# database = stargazer
# user = stg
# password = 123456
#Breaking open and converting to the required type store_mysql:
<DestStoreModule store_mysql>
#
dbuser = root
#
rootdbpass = ourpassword
#
dbname = stg
#
dbhost = localhost
We try to convert:
# ./convertor
An empty base is instantly converted. We are starting to configure stargazer.
We register traffic classes
# vim /etc/stargazer/rules
ALL 192.168.0.0/24 DIR1
ALL 0.0.0.0/0 DIR0
Fiddle under the realities of life config:
#vim /etc/stargazer/stargazer.conf
At least we rule the names of the directions:
DirName0 = internet
DirName1 = local
DirName2 =
DirName3 =
DirName4 =
DirName5 =
DirName6 =
DirName7 =
DirName8 =
DirName9 =
We build the cap_bpf traffic capture module so that it considers it on the interface looking into the internal network
<Module cap_bpf>
iface = fxp0
We comment on everything related to <StoreModule store_files> and, by analogy with the converter, we connect the <StoreModule store_mysql> module:
<StoreModule store_mysql>
dbuser = root
rootdbpass = ourpassword
dbname = stg
dbhost = localhost
We try to run the stargazer itself:
#stargazer
And check how they started
#tail /var/log/stargazer.log
If we see something similar to Stg started successfully. So there is a chance for life;)
We load windows configurator at stg.dp.ua/download/sgconfig/1.91.9/sgconfig.1.91.9.win.exe and after installation in the settings we set the connection to 192.168.0.1.
The default login / password is admin / 123456. After login, we should see something like
With the default test user here, feel free to delete.
Change the admin password, or add new ones. We add, on the basis of the old scheme for the test, our Maria Ivanovna from accounting with aipishka 192.168.0.2
It will be “always Online” with us because there is no need in the office environment to use auth_ia requiring you to specify a login / password to access the network.
In the fields UserData0 and UserData1 we drive in speed and MAC and that’s why:
The logic of the stargazer is very simple and flexible. When the user appears online, the following scripts are disconnected, deleted and added:
OnConnect
OnDisconnect
OnChange
OnUserAdd
OnUserDel
The purpose of which is easy to guess by their names. They are all located in / etc / stargazer /
We start to beat them under our realities
To begin with, we create another 2 scripts for PHP (not for nothing, we put it;) with the help of which we will get the speed and MAC of the user from the database.
Script / etc / stargazer / GetSpeed ​​with content
#!/usr/local/bin/php
<?php
$login=$argv[1];
$link = mysql_connect("localhost", "root", "ourpassword");
mysql_select_db("stg");
$query = 'SELECT `Userdata0` FROM users where `login`= "'.$login.'"';
$result = mysql_query($query);
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
foreach ($line as $col_value) {
print ($col_value);
}
}
?>
And / etc / stargazer / GetMac view
#!/usr/local/bin/php
<?php
$login=$argv[1];
$link = mysql_connect("localhost", "root", "ourpassword");
mysql_select_db("stg");
$query = 'SELECT `Userdata1` FROM users where `login`= "'.$login.'"';
$result = mysql_query($query);
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
foreach ($line as $col_value) {
print ($col_value);
}
}
?>
We assign them the rights to perform
#chmod a+x /etc/stargazer/GetMac /etc/stargazer/GetSpeed
Testing them on the topic of health for a previously created user:
# /etc/stargazer/GetSpeed mariya
512
/etc/stargazer/GetMac mariya
00:a1:b0:01:bc:77
Fine!
We start to think what will happen when the user appears online and falls offline.
So, what will happen when a user appears online:
# OnConnect
IFACE="fxp0"
LOGIN=$1
IP=$2
CASH=$3
ID=$4
SPEED=`/etc/stargazer/GetSpeed $LOGIN`
MAC=`/etc/stargazer/GetMac $LOGIN`
SCOUNT="Kbit/s"
fwcmd="/sbin/ipfw -q"
arpcmd="/usr/sbin/arp"
cur_date=`date \+\%Y.\%m.\%d`
cur_time=`date \+\%H:\%M:\%S`
# DELETE RULEZ
${fwcmd} delete `expr $ID '*' 10 + 10001`
${fwcmd} delete `expr $ID '*' 10 + 10002`
${fwcmd} delete `expr $ID '*' 10 + 10003`
${fwcmd} delete `expr $ID '*' 10 + 10004`
${fwcmd} delete `expr $ID '*' 10 + 10005`
# ADD RULEZ
# fix user mac to ip
${arpcmd} -S $IP $MAC
#SPEED CONTROL
${fwcmd} pipe `expr $ID + 101` config bw $SPEED$SCOUNT queue `expr $SPEED '/' 8`Kbytes
${fwcmd} pipe `expr $ID + 901` config bw $SPEED$SCOUNT queue `expr $SPEED '/' 8`Kbytes
# ALLOWS CONTROL
${fwcmd} add `expr $ID '*' 10 + 10001` allow icmp from $IP to me
${fwcmd} add `expr $ID '*' 10 + 10001` allow icmp from me to $IP
${fwcmd} add `expr $ID '*' 10 + 10002` pipe `expr $ID + 101` ip from $IP to any via $IFACE in
${fwcmd} add `expr $ID '*' 10 + 10003` pipe `expr $ID + 901` ip from any to $IP via $IFACE out
${fwcmd} add `expr $ID '*' 10 + 10004` allow ip from $IP to any
${fwcmd} add `expr $ID '*' 10 + 10005` allow ip from any to $IP
# ADD TO LOG
echo "<=;$cur_date;$cur_time;$ID;$LOGIN;$IP;$CASH;$SPEED;`expr $ID + 101`;$MAC" >> /var/stargazer/allconnect.log
and what will happen if it falls out of the online:
# OnDisconnect
LOGIN=$1
IP=$2
CASH=$3
ID=$4
fwcmd="/sbin/ipfw -q"
# TIME FORMAT
cur_date=`date \+\%Y.\%m.\%d`
cur_time=`date \+\%H:\%M:\%S`
# DELETE RULEZ FRO IPFW
${fwcmd} delete `expr $ID '*' 10 + 10001`
${fwcmd} delete `expr $ID '*' 10 + 10002`
${fwcmd} delete `expr $ID '*' 10 + 10003`
${fwcmd} delete `expr $ID '*' 10 + 10004`
${fwcmd} delete `expr $ID '*' 10 + 10005`
${fwcmd} pipe `expr $ID + 101` delete
${fwcmd} pipe `expr $ID + 901` delete
echo "=>;$cur_date;$cur_time;$ID;$LOGIN;$IP;$CASH" >> /var/stargazer/allconnect.log
I think everything is clear here - we just raise / delete the corresponding shaping rules for the user's ID and make it allow further than our local fxp0 interface.
I remember from the beginning, they were not limited to anything, because at the very end stood allow ip from any to any? No problems.
Add something like to /etc/firewall.conf
${FwCMD} add 101 allow all from 192.168.0.1 to any
${FwCMD} add 101 allow all from any to 192.168.0.1
${FwCMD} add 65533 deny all from table\(2\) to any
${FwCMD} add 65534 deny all from any to table\(2\)
Now we try to enable / disable "always Online" for our experimental user and look at /var/stargazer/allconnect.log
Mistress note : it is always useful to control by eye what and how it goes and according to what rules with
#ipfw show
All - in the minimum version of the billing delivered. You ask, why should we count money? It's very simple - we wanted our Marivanovna to give out no more than 500 meg Internet per month or simply to give her a certain speed with a certain amount of traffic to her manually as needed? No problems. Just equate 1 meg to one denyuzhke for ease of calculation. Suppose so
In general, there is room for creativity.
In my opinion, the article turned out to be some kind of extremely long and gloomy. Clearly it's time to get round.
Next time, if karma allows me to promise to tell you how to make a switch to the backup channel, draw such beautiful graphics with cacti
and how convenient it is to arrange the display of statistics on the traffic collected by the stargazer we set today.
Threat and yes - my Russian unlearned at school since the previous time has not regrettably not improved :(
Source: https://habr.com/ru/post/71053/
All Articles