Библиотека сайта rus-linux.net
Создаем VPN на основе vtun (стр.3)
Теперь можно попробовать, как работает наша виртуальная частная сеть. Выполним команду ping на хостах vpn_filial и vpn_office. Таким образом мы сможем проверить прохождение пакетов от vpn_filial к vpn_office и от vpn_shop к vpn_office.
vpn_filial# ping 192.168.30.251 PING 192.168.30.251 (192.168.30.251): 56 data bytes 64 bytes from 192.168.30.251: icmp_seq=0 ttl=64 time=5.788 ms 64 bytes from 192.168.30.251: icmp_seq=1 ttl=64 time=5.724 ms 64 bytes from 192.168.30.251: icmp_seq=2 ttl=64 time=5.683 ms 64 bytes from 192.168.30.251: icmp_seq=3 ttl=64 time=5.685 ms --- 192.168.30.251 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 5.683/5.720/5.788 ms vpn_office# ping 192.168.40.251 PING 192.168.30.251 (192.168.30.251): 56 data bytes 64 bytes from 192.168.40.251: icmp_seq=0 ttl=64 time=6.092 ms 64 bytes from 192.168.40.251: icmp_seq=1 ttl=64 time=5.785 ms 64 bytes from 192.168.40.251: icmp_seq=2 ttl=64 time=5.851 ms 64 bytes from 192.168.40.251: icmp_seq=3 ttl=64 time=5.826 ms --- 192.168.30.251 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.785/5.888/6.092/0.120 ms
Судя по всему, туннели исправно передают пакеты в обе стороны и все работает
наилучшим образом. Теперь давайте проверим, как работает шифрование. Нужно помотреть,
что и в каком виде передается по интерфейсам tun0 - 192.168.0.2 и ed1 - 80.80.20.2.
Давайте начнем прослушивание интерфейсов, участвующих в передаче данных, с помощью
программы tcpdump. В тоже время с машины vpn_shop начинаем пинговать интерфейс
192.168.40.251 принадлежащий машине vpn_office.
vpn_office# tcpdump -i tun0 -lenx
13:33:14.573619 AF 2 84: 192.168.0.2 > 192.168.40.251: icmp: echo request
4500 0054 0cc3 0000 4001 c398 c0a8 0002
c0a8 28fb 0800 edcc c904 0000 ede7 cc3d
9505 0700 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
13:33:14.573665 AF 2 84: 192.168.40.251 > 192.168.0.2: icmp: echo reply
4500 0054 1b3f 0000 4001 b51c c0a8 28fb
c0a8 0002 0000 f5cc c904 0000 ede7 cc3d
9505 0700 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
13:33:15.583143 AF 2 84: 192.168.0.2 > 192.168.40.251: icmp: echo request
4500 0054 0cc6 0000 4001 c395 c0a8 0002
c0a8 28fb 0800 42a6 c904 0100 eee7 cc3d
3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
13:33:15.583194 AF 2 84: 192.168.40.251 > 192.168.0.2: icmp: echo reply
4500 0054 1b43 0000 4001 b518 c0a8 28fb
c0a8 0002 0000 4aa6 c904 0100 eee7 cc3d
3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
13:33:16.590000 AF 2 84: 192.168.0.2 > 192.168.40.251: icmp: echo request
4500 0054 0cc6 0000 4001 c395 c0a8 0002
c0a8 28fb 0800 42a6 c904 0100 eee7 cc3d
3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
13:33:16.590120 AF 2 84: 192.168.40.251 > 192.168.0.2: icmp: echo reply
4500 0054 1b43 0000 4001 b518 c0a8 28fb
c0a8 0002 0000 4aa6 c904 0100 eee7 cc3d
3e2c 0700 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
На предыдущем листинге явно видно содержимое тестовых ICMP пакетов. А теперь
внимательно посмотрим, в каком виде эти пакеты путешествуют по небезопасной
сети 80.80.20.0/24.
vpn_office# tcpdump -i ed1 -lenx
13:33:14.573441 0:40:95:45:9c:e2 0:2:b3:65:f:47 0800 140: 80.80.20.2.5000 > 80.80.20.3.1035: udp 98
4500 007e 0cc4 0000 4011 a506 5050 1402
5050 1403 1388 040b 006a f9e2 0060 7db0
f6ef dd81 4638 917a 5a80 7f48 87d7 7bc9
459f 97f0 b95a 95cf 87b1 29ce b2d7 8f50
228e 6b8f eafb 1f5d ae9d 7518 2085 2da9
8c85
13:33:14.574798 0:2:b3:65:f:47 0:40:95:45:9c:e2 0800 140: 80.80.20.3.1035 > 80.80.20.2.5000: udp 98
4500 007e 1b40 0000 4011 968a 5050 1403
5050 1402 040b 1388 006a 998c 0060 7db0
f6ef dd81 4638 5390 c84e 886e 466d ffcd
df10 9010 5995 fcdd b315 92fb 6a1d 8f50
228e 6b8f eafb 1f5d ae9d 7518 2085 2da9
8c85
13:33:15.582910 0:40:95:45:9c:e2 0:2:b3:65:f:47 0800 140: 80.80.20.2.5000 > 80.80.20.3.1035: udp 98
4500 007e 0cc7 0000 4011 a503 5050 1402
5050 1403 1388 040b 006a 28fd 0060 7db0
f6ef dd81 4638 3048 4e92 e692 1c3d 5fa3
c2a6 bc50 8fa5 79d3 c0c2 6537 c74b 1e84
b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9
8c85
13:33:15.584332 0:2:b3:65:f:47 0:40:95:45:9c:e2 0800 140: 80.80.20.3.1035 > 80.80.20.2.5000: udp 98
4500 007e 1b44 0000 4011 9686 5050 1403
5050 1402 040b 1388 006a cd92 0060 7db0
f6ef dd81 4638 f41d cb55 f37d 1229 dbb6
14f7 14d1 08e3 a204 5045 74a0 7807 1e84
b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9
8c85
13:33:15.593910 0:40:95:45:9c:e2 0:2:b3:65:f:47 0800 140: 80.80.20.2.5000 > 80.80.20.3.1035: udp 98
4500 007e 0cc7 0000 4011 a503 5050 1402
5050 1403 1388 040b 006a 28fd 0060 7db0
f6ef dd81 4638 3048 4e92 e692 1c3d 5fa3
c2a6 bc50 8fa5 79d3 c0c2 6537 c74b 1e84
b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9
8c85
13:33:15.594237 0:2:b3:65:f:47 0:40:95:45:9c:e2 0800 140: 80.80.20.3.1035 > 80.80.20.2.5000: udp 98
4500 007e 1b44 0000 4011 9686 5050 1403
5050 1402 040b 1388 006a cd92 0060 7db0
f6ef dd81 4638 f41d cb55 f37d 1229 dbb6
14f7 14d1 08e3 a204 5045 74a0 7807 1e84
b95e c8f8 6048 3d3c 4f33 32a4 25a2 2da9
8c85
Как мы могли убедиться все пакеты движутся через публичную сеть в зашифрованом виде. Мы создали туннели VPN1 и VPN2 между тремя частными сетями. Теперь машина vpn_office сможет общаться с любой машиной из всех трех сетей. Но в то же время машины vpn_shop и vpn_filial могут взаимодействовать лишь с машиной vpn_office, но не друг с другом. При таком способе соединения сетей у нас получилась топология типа звезда. Такая конструкция не очень надежна. Если хост vpn_office по каким-либо причинам выйдет из строя, вся система VPN перестанет существовать. Что бы избежать подобных плачевных результатов нам необходимо создать резервный туннель VPN3 между хостами vpn_shop и vpn_filial. Это даст им возможность работать друг с другом напрямую не полагаясь на хост vpn_office.
В файл конфигурации хоста vpn_shop добавим настройки нового туннеля. Я надеюсь что Вы уже можете самотоятельно разобраться в то что они значат.
filial_to_shop {
pass secret;
type tun;
proto udp;
encr yes;
keepalive yes;
up {
ifconfig "%% 192.168.0.3 netmask 255.255.255.0 192.168.0.1 up";
route "add net 192.168.20.0 192.168.0.1 1";
};
down {
ifconfig "%% down";
route "delete net 192.168.20.0 192.168.0.1 1";
};
Затем запускаем сервер:
vpn_shop# vtund -s
В свою очередь в конфигурацию хоста vpn_filial добавим вот такие строки:
filial_to_shop {
pass secret;
type tun;
proto udp;
encr yes;
keepalive yes;
up {
ifconfig "%% 192.168.0.1 pointopoint 192.168.0.3 mtu 1450";
route "add -net 192.168.30.0/24 192.168.0.3";
};
down {
ifconfig "%% down";
route "delete -net 192.168.30.0 ";
};
А теперь запускаем клиента :
vpn_shop# vtund -p filial_to_shop 80.80.20.1
Таким образом у нас появляется еще один туннель. Я надеюсь что заботясь о безопасности
Вы догадались поменять во всех конфигурационных файлах пароль соединения. После
этого необходимо перезапустить демонов и клиентов. Теперь главное - не забыть
установить на клиентских машинах трех сетей правильные адреса шлюза по умолчанию.
После того как эта работа будет завершена можно со спокойной совестью отдыхать.
| страницы | 1, 2, 3 |
|
предыдущая |