www.metincom.net Самуил Арсов
Конфигуриране на IP адрес, route и DNS сървъри
ifconfig eth0 10.25.3.5 netmask 255.255.255.0
route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.25.3.1
Във файла /etc/resolv.conf с любим текстов редактор (mcedit, pico, nano) създаваме запис на DNS сървъри.
nameserver 10.21.1.3
nameserver 10.21.1.2
Изтегляне и инсталиране pptp
wget -c http://10.21.1.4/vpn_client/slackware/pptp-1.7.1-i486-2ga.tgz
installpkg pptp-1.7.1-i486-2ga.tgz
Свървзване към pptp сървъра
Заменете username и pass с вашите лични потребителско име и парола.
pptp 10.21.1.3 user username password pass defaultroute
ifconfig eth0 10.25.3.5 netmask 255.255.255.0
route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.25.3.1
pptp 10.21.1.3 user username password pass defaultroute
Можете да запишете горните 3 реда в /etc/rc.d/rc.local файла, за да се изпълняват командите, всеки път, когато се зарежда системата - но при положение, че не сте конфигурирали ип адреса, маската и default gateway вече в графична среда или текстова конзола по време или след инсталацията на дистрибуцията. Проверете файла /etc/rc.d/rc.inet1.conf и просто изтрийте съдържанието в кавичките в редове IPADDR[0]="", NETMASK[0]="", GATEWAY="" след което рестартирате системата с командата reboot и проверявате с ifconfig има ли вдигнат eth0 интерфейс. Запомнете, че в този случай не трябва да имате конфигуриран default gateway, а само маршрут към мрежа 10.0.0.0 default gateway се вдига от опцията defaultroute на командата pptp.
Ако имаме проблем и предприемем диагностика, първата команда, която изпълняваме, е ifconfig. ifconfig тярбва да ни покаже lo, eth0 и ppp0 интерфейси. Ето как изглежда отговора на командата ifconfig на моята машина:
root@sami-laptop:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:FC:EC:43:F2
inet addr:10.25.3.5 Bcast:10.25.3.255 Mask:255.255.255.0
inet6 addr: fe80::219:d2ff:fe83:f509/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:97 errors:0 dropped:55959 overruns:0 frame:0
TX packets:106 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1003369176 (956.8 MiB) TX bytes:141391831 (134.8 MiB)
Interrupt:17 Base address:0xa000 Memory:fdfff000-fdffffff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:539 errors:0 dropped:0 overruns:0 frame:0
TX packets:539 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:17522 (17.1 KiB) TX bytes:17522 (17.1 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:172.16.21.1 P-t-P:195.138.153.78 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:966 errors:8 dropped:0 overruns:0 frame:0
TX packets:1275 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:357425 (349.0 KiB) TX bytes:137914 (134.6 KiB)
Често се случва да не се вдигне pptp интерфейса и първите възможни причини за това са:
Неправилно описани потребителско име и парола или грешно зададен маршрут с командата route. Ето пример как трябва да изглежда отговора на
командата route:
root@sami-laptop:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ns1.metincom.net * 255.255.255.255 UH 0 0 0 ppp0 localnet * 255.255.255.0 U 0 0 0 eth0 10.0.0.0 10.25.3.1 255.0.0.0 UG 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default * 0.0.0.0 U 0 0 0 ppp0
Пак повтарям, защото е важно: default gateway не е 10.25.3.1, а виртуалният интерфейс ppp0 !!!
Една клиентска машина като нас не трябва да има два зададени default gateway (това е приоритет на маршрутизаторите).
Реда route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.25.3.1 описва маршрут към всички ип адреси от 10-та мрежа.
Опцията defaultroute на командата pptp създава default gateway към интерфейса ppp0 и маршрут към всички ип адреси (интернет).
Ако имаме неправилно зададен default gateway, можем да го изтрием с командата route del default.
Ако нямаме default gateway към ppp0, а интерфейса съществува вече, изпълняваме route add default dev ppp0 - изглежда по-различно от defaultroute
на командата pptp, но прави същото нещо (създава маршрут през ppp0 към интернет).
Има случаи, в които искаме да спрем ppp0 или пък имаме два ppp интерфейса. ppp-off по подразбиране убива ppp0, но с опцията
ppp-off ppp1 например ще терминира ppp1.
Ако потребителското име, паролата и маршрута с командата route са правилни, преминаваме към командата пинг. ping използва
протокола icmp като част от работата му е да тества свързаност между хостове в мрежата.
ping 10.25.3.5 ще провери собсвената ми мрежова карта
ping 10.25.3.1 ще провери локалния маршрутизатор
ping 10.21.1.3 ще провери свързаноста с VPN сървъра
ping dir.bg ще провери достъпваме ли машината, на която се хоства сайта http://www.dir.bg
Идеалния вариянт е, когато получим подобен отговор:
root@sami-laptop:~# ping dir.bg PING dir.bg (194.145.63.12) 56(84) bytes of data 64 bytes from dir.bg (194.145.63.12): icmp_seq=1 ttl=57 time=14.2 ms 64 bytes from dir.bg (194.145.63.12): icmp_seq=2 ttl=57 time=11.2 ms 64 bytes from dir.bg (194.145.63.12): icmp_seq=3 ttl=57 time=10.9 ms --- dir.bg ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 10.952/12.129/14.219/1.484 ms
Малко пояснение: командата пинг изпраща пакет с големина 64 bytes към името dir.bg, което отговаря на ип адрес 194.145.63.12 посредством протокола icmp с време на живот ttl=57 (от 64 възможни има още 57 хопа) получаваме отговор от dir.bg time= на едиколко си милисекунди.
Следващ вариант е, ако получим подобен отговор:
root@sami-laptop:/etc# ping dir.bg connect: Network is unreachable
Нямаме default gateway през ppp0 или въобще не съществува такъв интерфейс ppp0.
също има и вариант промпта един вид да замръзне в това състояние без да ни дава никакъв отговор
root@sami-laptop:/etc# ping dir.bg
Причината е неправилно конфигуриран или неработещ DNS. Това се случва, защото командата пинг не знае кой е ип адреса на сайта dir.bg и чака отговор от DNS сървъра да окаже това.
Възможно е, но малко вероятно, някъде по маршрута ни до впн сървъра или към интернет да има дефектирало устройство или маршрутизатор. Тази
ситуация се проверява с една другa също много важна команда traceroute. Поради факта, че имаме два маршрута - един през eth0
и един през виртуалния интерфейс ppp0, ще използваме командата два пъти.
Проверка на маршрута до впн сървъра:
root@sami-laptop:/etc# traceroute 10.21.1.3 traceroute to 10.21.1.3 (10.21.1.3), 30 hops max, 38 byte packets 1 10.25.3.1 (10.25.3.1) 1.507 ms 1.731 ms 3.013 ms 2 * * * 3 10.21.1.3 (10.21.1.3) 1.657 ms 1.732 ms 1.153 ms
И проверка на маршрута до dir.bg:
root@sami-laptop:/etc# traceroute dir.bg traceroute to dir.bg (194.145.63.12), 30 hops max, 38 byte packets 1 ns1.metincom.net (195.138.153.78) 1.940 ms 1.677 ms 1.679 ms 2 195.138.153.77 (195.138.153.77) 1.774 ms 1.777 ms 1.787 ms 3 195.138.132.254 (195.138.132.254) 2.249 ms 2.071 ms 2.111 ms 4 85.95.85.45 (85.95.85.45) 7.000 ms 5.902 ms 6.374 ms 5 ssrv7-bg-gw.tpnbg.net (212.56.30.125) 5.871 ms 6.074 ms 5.990 ms 6 unknown.tpnbg.net (195.138.150.238) 6.092 ms 6.251 ms 5.852 ms 7 dir.bg (194.145.63.12) 6.046 ms 5.953 ms 5.914 ms
Макар, че traceroute dir.bg минава и през първия маршрут 10.21.1.3 показва съвсем различен път. Причината за това е виртуалния интерфеис. ppp0 е виртуална директна връзка до впн сървъра, преминаваща през реалната eth0 и имено затова пътя на ppp0 тръгва от впн сървъра през интернет до хоста, които сме указали. Всеки един ред в отговора на командата се нарича хоп или това е маршрутизатора, през който преминават нашите пакети. Когато промпта спре на някой ред и последват само звездички, нашият път стига до там и не можем да продължим по някаква причина. Дали това е повреда, прекъснат кабел, дефектирал комутатор, техническа неизправност или маршрутизатора реже нашите пакети, не можем да знаем.
Варианта, в който дори няма пинг до локалния маршрутизатор 10.25.3.1 и traceroute стигне само до там е много смущаващ. В такъв момент се получава объркване дали проблема наистина не е в клиента. Първо можем да проверим дали има около нас други хостове.
root@sami-laptop:~# nmap -sP 10.25.3.0/24 Starting Nmap 4.50 ( http://insecure.org ) at 2008-03-03 11:38 EET Host 10.25.3.1 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.2 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.4 appears to be up. MAC Address: 00:0D:61:3E:04:D4 (Giga-Byte Technology Co.) Host 10.25.3.5 appears to be up. Host 10.25.3.7 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.9 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.12 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.13 appears to be up. MAC Address: 00:04:75:9E:15:7D (3 Com) Host 10.25.3.14 appears to be up. MAC Address: 00:20:ED:5E:3A:07 (Giga-byte Technology CO.) Host 10.25.3.24 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.26 appears to be up. MAC Address: 00:02:44:7C:9E:94 (Surecom Technology Co.) Host 10.25.3.28 appears to be up. MAC Address: 00:16:D4:FC:7B:2A (Compal Communications) Host 10.25.3.32 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.33 appears to be up. MAC Address: 00:15:58:A6:DD:1A (Foxconn) Host 10.25.3.34 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.35 appears to be up. MAC Address: 00:16:B6:C3:76:51 (Cisco-Linksys) Host 10.25.3.36 appears to be up. MAC Address: 00:09:B7:38:90:00 (Cisco Systems) Host 10.25.3.37 appears to be up. MAC Address: 00:D0:B7:C9:36:E2 (Intel) map done: 256 IP addresses (46 hosts up) scanned in 1.581 seconds
Това е лист на съседните хостове около мен в моя клас мрежа 10.25.3.Х съответно с ип и мак адреси, по което съдим, че щом виждаме нашите съседи, машината си ни е наред.
Ако имаме свързаност (пинг) с впн сървъра и въпреки това не можем да вдигнем pptp интерфейс с nmap, можем да проверим отворен ли е порта, на който впн сървъра слуша за клиенти като нас.
root@sami-laptop:~# nmap 10.21.1.3 -p 1723 Starting Nmap 4.50 ( http://insecure.org ) at 2008-03-03 18:32 EET Interesting ports on 10.21.1.3: PORT STATE SERVICE 1723/tcp open pptp Nmap done: 1 IP address (1 host up) scanned in 0.101 seconds
Възможните отговори са closed - порта въобще не слуша, filtered - филтрира се от защитна стена и open - работещ, какъвто трябва да бъде.
www.metincom.net Самуил Арсов