1. How to reach Nginx being hosted via IPv4

How to reach Nginx being hosted via IPv4

Home Forums FABRIC General Questions and Discussion How to reach Nginx being hosted via IPv4

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #6962
    Jacob Goldverg
    Participant

      Hello All,

      I currently have Nginx running with an IPv4 address. I am unable to ping/traceroute/curl the instance, from my laptop I am fully able too. Is there anyway to configure my instance running in STAR to connect to an IPv4 address?

      I already tried running the nat64.sh script provided in https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/fablib_api/accessing_ipv4_services_from_ipv6_nodes/nat64.sh but this did not resolve the issue.

      Best,

      Jacob

      #6963
      Komal Thareja
      Participant

        FABRIC only allows SSH and few ICMP messages over the management interface. Hosting services on management network is not recommended. Instead, we recommend using data plane network for your service.

        FABRIC serves as a secure sandbox, allowing students and researchers to experiment with potentially disruptive and vulnerable software architectures in a protected environment. When connecting external devices, such as laptops or servers, to nodes within a slice, it is crucial to employ secure methods like SSH tunnels. A Jupyter notebook example illustrates how to create SSH tunnels through the FABRIC bastion host. Alternatively, users can utilize personal VPNs like Tailscale for secure connections.

        Exposing ports to the entire Internet is restricted, reserved only for exceptional cases where alternative solutions are not viable. Moreover, users undertaking such capabilities are responsible for deploying, maintaining, and ensuring the security of experiments, akin to a production data center. IPv4Ext and IPv6Ext services facilitate these capabilities.

        For newcomers, getting acquainted with SSH tunnels is recommended due to their simplicity and security. If users have additional questions or require further guidance, they are encouraged to reach out.

        Thanks,

        Komal

        #6964
        Jacob Goldverg
        Participant

          Hello Komal,

          Sorry for the misunderstanding this was poorly written.
          To clarify my setup. I have Nginx running in AWS with an IPv4 elastic IP address. I am trying to connect my fabric instance to the Nginx server to download some files I am hosting. In your response it implies that I am hosting NGINX inside of Fabric which is not the case.

          My server is publicly hosted elsewhere and I just want to download data from it into Fabric. To me I think I am having some sort of DNS issue.

           

          So sorry for the confusion.

           

          Best,

          Jacob

          #6965
          Komal Thareja
          Participant

            Hi Jacob,

            Thank you for clarifying your setup. FABRIC is now running it’s own NAT gateway. All VMs are configured to use it for NAT resolution so IPv4 addresses should be accessible.

            Could you please share your slice ID? I’ll check your slice and share my findings.

            Thanks,

            Komal

            • This reply was modified 6 months, 3 weeks ago by Komal Thareja.
            #6967
            Jacob Goldverg
            Participant

              Sure,

              Here is the slice ID: a555e017-fc56-4c3c-8ef4-b3c10093c160

               

              Best,

              Jacob

              #6970
              Komal Thareja
              Participant

                Hi Jacob,

                I noticed that /etc/resolv.confwas updated on your VM probably via nat64.sh. I reverted it back to the default as shown below. Your original file is saved as /etc/resolv.conf.bkp.

                With this change, I was able to ping github.com an IPV4 domain. IPv4 subnets should be reachable. Please note nat64.sh is no longer required. I will update the Knowledge base article also to reflect this.

                root@TransferNode:/etc# cat /etc/resolv.conf
                # This file is managed by man:systemd-resolved(8). Do not edit.
                #
                # This is a dynamic resolv.conf file for connecting local clients to the
                # internal DNS stub resolver of systemd-resolved. This file lists all
                # configured search domains.
                #
                # Run "resolvectl status" to see details about the uplink DNS servers
                # currently in use.
                #
                # Third party programs must not access this file directly, but only through the
                # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
                # replace this symlink by a static file or a different symlink.
                #
                # See man:systemd-resolved.service(8) for details about the supported modes of
                # operation for /etc/resolv.conf.

                nameserver 127.0.0.53
                options edns0 trust-ad
                search openstacklocal

                root@TransferNode:/etc# ping -c2 github.com
                PING github.com(lb-140-82-112-4-iad.github.com (2600:2701:5000:5001::8c52:7004)) 56 data bytes
                64 bytes from lb-140-82-112-4-iad.github.com (2600:2701:5000:5001::8c52:7004): icmp_seq=1 ttl=230 time=88.4 ms
                64 bytes from lb-140-82-112-4-iad.github.com (2600:2701:5000:5001::8c52:7004): icmp_seq=2 ttl=230 time=87.4 ms

                --- github.com ping statistics ---
                2 packets transmitted, 2 received, 0% packet loss, time 1002ms
                rtt min/avg/max/mdev = 87.439/87.930/88.422/0.491 ms
                root@TransferNode:/etc#

                Thanks,

                Komal

                • This reply was modified 6 months, 3 weeks ago by Komal Thareja.
                #6973
                Jacob Goldverg
                Participant

                  Hello Komal,

                  My previous slice died and I just launched a new one for a week and I am experiencing the same issue unfortunately.

                  When I run: ping 129.114.108.207 using curl or wget as well I get a “Couldn’t connect to server” sadly.

                  My current sliceId is: 67a7dad9-ce04-47b0-89af-bdb15f7f55de

                  This time I did not run the nat64.sh script.

                  Best,

                  Jacob

                  #6974
                  Komal Thareja
                  Participant

                    Hi Jacob,

                    I used nslookup to determine the FQDN for your server and can confirm that I can ping your host as shown below.
                    SALT is IPv6-only site. I will check and confirm if FABRIC NAT server config needs changes to enable this. But the reachability is working with FQDN/hostname.


                    root@TransferNode:~# nslookup 129.114.108.207
                    207.108.114.129.in-addr.arpa name = chi-dyn-129-114-108-207.tacc.chameleoncloud.org.


                    root@TransferNode:~#
                    root@TransferNode:~#
                    root@TransferNode:~#
                    root@TransferNode:~# ping chi-dyn-129-114-108-207.tacc.chameleoncloud.org
                    PING chi-dyn-129-114-108-207.tacc.chameleoncloud.org(chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf)) 56 data bytes
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=1 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=2 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=3 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=4 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=5 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=6 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=7 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=8 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=9 ttl=35 time=113 ms
                    64 bytes from chi-dyn-129-114-108-207.tacc.chameleoncloud.org (2600:2701:5000:5001::8172:6ccf): icmp_seq=10 ttl=35 time=113 ms

                    Thanks,
                    Komal

                  Viewing 8 posts - 1 through 8 (of 8 total)
                  • You must be logged in to reply to this topic.