Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Как реализовать TFTP через openVPN (tap)?

    Scheduled Pinned Locked Moved Russian
    13 Posts 3 Posters 2.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N Offline
      NiXeon
      last edited by

      tftp сервер ошибок не сообщает, полагаю до него просто не доходит запрос. В логах ничего необычного. Во floating ничего на обоих шлюзах нет. Правила во вложении. Правила openVPN одинаковые на обоих шлюзах.

      0.png
      0.png_thumb
      1.png
      1.png_thumb
      2.png
      2.png_thumb

      1 Reply Last reply Reply Quote 0
      • werterW Offline
        werter
        last edited by

        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 Reply Last reply Reply Quote 0
        • N Offline
          NiXeon
          last edited by

          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  unknown

          69 порта нигде нет, хотя в брэндмаузере стоит исключение. Даже через политику добавил исключение, не помогло.

          Сканирование по порту 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 308

          192.168.100.250 - виртуальная машина, с которой тестирую.
          192.168.101.2 - tftp сервер, который должен отвечать клиентам

          0.png
          0.png_thumb
          1.png
          1.png_thumb
          2.png
          2.png_thumb

          1 Reply Last reply Reply Quote 0
          • werterW Offline
            werter
            last edited by

            Доброе.
            А почему портов udp 67-68 dhcp нет в открытых ? Они же нужны, да ?

            1 Reply Last reply Reply Quote 0
            • N Offline
              NiXeon
              last edited by

              Потому-что DHCP работает на шлюзе pfsense, а на этом сервере нет служб DHCP

              1 Reply Last reply Reply Quote 0
              • werterW Offline
                werter
                last edited by

                Попробуйте сбриджевать (создать мост) инт., на к-ом живет dhcp и впн-инт.

                1 Reply Last reply Reply Quote 0
                • N Offline
                  NiXeon
                  last edited by

                  Клиент увидел TFTP, но нестабильно работает. Клиент увидел TFTP только когда на обоих шлюзах объединил интерфейсы LAN и OVPN, но получалось загрузить 1-2 раза, затем снова переставал видеть сервер TFTP (полагаю из-за конфликтов между DHCP-серверами на шлюзах, так-как в режиме моста их LAN'ы смотрят напрямую друг в друга). Сделать мост только на одном шлюзе, а потом только на другом не возымело никакого фифекта

                  1 Reply Last reply Reply Quote 0
                  • werterW Offline
                    werter
                    last edited by

                    Попробуйте исп. тот же ipsec вместо openvpn . напр.
                    Или gre

                    1 Reply Last reply Reply Quote 0
                    • S Offline
                      Scodezan
                      last edited by

                      werter, очень сильно сомневаюсь что поможет. Тут либо мост, либо какой-то tftp прокси(пакет tftp proxy, штатный NAT, проброс программой 3proxy).

                      1 Reply Last reply Reply Quote 0
                      • werterW Offline
                        werter
                        last edited by

                        Я бы l2tp попробовал. И не выделял бы отдельн. сеть , а назначил бы свободный адрес из локальной сети при подкл.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.