Как реализовать TFTP через openVPN (tap)?
-
Доброе
Что в логах самого tftp? Есть ли к нему обращение клиента ? Может есть ошибки ?
Правила fw на Openpvn и LAN обоих пф покажите. Во floating rules ничего лишнего ? -
tftp сервер ошибок не сообщает, полагаю до него просто не доходит запрос. В логах ничего необычного. Во floating ничего на обоих шлюзах нет. Правила во вложении. Правила openVPN одинаковые на обоих шлюзах.
-
1. Доступен ли из 192.168.100.0/24 192.168.101.2 ? И не просто icmp\ping, но и nmap из 192.168.100.0/24 отсканить какие порты доступны на 192.168.101.2.
2. В правилах встроенного в Win fw на 192.168.101.2 разрешить доступ из 192.168.100.0/24. Он там 100% запрещен. -
1. 192.168.101.2 доступен, но по портам nmap сканирует только через ключ -Pn
PORT STATE SERVICE
42/tcp open nameserver
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
1688/tcp open nsjtp-data
1947/tcp open sentinelsrm
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
3389/tcp open ms-wbt-server
5357/tcp open wsdapi
9080/tcp open glrpc
9081/tcp open unknown
49152/tcp open unknown
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49157/tcp open unknown
49158/tcp open unknown
49165/tcp open unknown69 порта нигде нет, хотя в брэндмаузере стоит исключение. Даже через политику добавил исключение, не помогло.
Сканирование по порту 69 выглядит так:
PORT STATE SERVICE VERSION
69/tcp filtered tftpСканировал из подсети 192.168.100.0/24.
Дубли в брендмаузере появились после того как политикой добавил правила.
Теперь понятно почему не работает tftp, спасибо. Но не понятно почему порты закрыты.
UPD: сканировал еще со шлюзов 192.168.100.254 и 192.168.101.254 (одинаковый результат):
69/udp open|filtered tftp
69/tcp filtered tftpЧто странно, запрос даже не приходит на шлюз 192.168.101.254. tcpdump'ом проверил, нет на VPN интерфейсах обоих шлюзов ни одного пакета от клиента. Зато на lan-интерфейсе 192.168.100.254 есть такие пакеты:
192.168.100.250/root: tcpdump -i rl0 | grep "192.168.100.250"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:12:13.631060 IP komsomol.###.bootps > 192.168.100.250.bootpc: BOOTP/DHCP, Reply, length 308
11:12:14.616032 IP komsomol.###.bootps > 192.168.100.250.bootpc: BOOTP/DHCP, Reply, length 308
11:12:16.593610 IP komsomol.###.bootps > 192.168.100.250.bootpc: BOOTP/DHCP, Reply, length 308192.168.100.250 - виртуальная машина, с которой тестирую.
192.168.101.2 - tftp сервер, который должен отвечать клиентам
-
Доброе.
А почему портов udp 67-68 dhcp нет в открытых ? Они же нужны, да ? -
Потому-что DHCP работает на шлюзе pfsense, а на этом сервере нет служб DHCP
-
Попробуйте сбриджевать (создать мост) инт., на к-ом живет dhcp и впн-инт.
-
Клиент увидел TFTP, но нестабильно работает. Клиент увидел TFTP только когда на обоих шлюзах объединил интерфейсы LAN и OVPN, но получалось загрузить 1-2 раза, затем снова переставал видеть сервер TFTP (полагаю из-за конфликтов между DHCP-серверами на шлюзах, так-как в режиме моста их LAN'ы смотрят напрямую друг в друга). Сделать мост только на одном шлюзе, а потом только на другом не возымело никакого фифекта
-
Попробуйте исп. тот же ipsec вместо openvpn . напр.
Или gre -
werter, очень сильно сомневаюсь что поможет. Тут либо мост, либо какой-то tftp прокси(пакет tftp proxy, штатный NAT, проброс программой 3proxy).
-
Я бы l2tp попробовал. И не выделял бы отдельн. сеть , а назначил бы свободный адрес из локальной сети при подкл.
