Layer7 API Management

  • Private Community

  • 1.  telnet

    Posted Jul 26, 2018 12:41 PM

    Hi There,

    Telnet is not working in API gateway 9.2 vm seems that pkg is installed , please advice how could I install it



  • 2.  Re: telnet
    Best Answer

    Posted Jul 26, 2018 08:10 PM

    Hello Sharath,

     

    The telnet package is not included in any of the CA-issued OVA images we use for our Gateway appliances, as they ship out of the box as a hardened operating system, meaning many of the default packages in a CentOS or RHEL appliance is not included in the ones we create if they're not necessary or critical in some way to the operation of the actual Gateway application.

     

    If you're wanting to install telnet in your environment, you'll need to find the telnet RPM from a trusted source. That source is entirely up to you, but my advice is to obtain it from an official mirror of the operating system, such as this one for CentOS (the RPM packages should apply to both CentOS and RHEL in this case): http://mirror.csclub.uwaterloo.ca/centos/7/os/x86_64/Packages/

     

    From the link above, you'll find the telnet RPM listed on that page. You can then download it, upload to the Gateway, and install it using the appropriate rpm command.

     

    As this post has to do with help installing a third-party tool (which isn't something we are really responsible for as it can potentially have unintended consequences), I must preface all of the above with the following official statement on third-party tools for use on the Gateway:

     

    When possible, we recommend that you utilize the API Gateway's built-in functionality before installing external applications. When the API Gateway's built-in functionality does not meet your requirements, we permit our customers to install additional applications without terminating or negatively impacting the support agreement between your organization and ours.

    As with any change to the API Gateway, we strongly recommend that thorough testing in non-critical environments is carried out before escalating the deployment to more business-critical production systems. Please keep in mind that we may request that this software / application be removed from the system during subsequent support requests where we feel the third-party application may be interfering with the proper operation of the API Gateway.

    Lastly, we do not include updates for external applications, tools, or their dependencies in API Gateway patches or platform updates. Upgrading an appliance may cause previously working configurations of your third-party tool to break, and such action would not be supported by CA Technologies. Since we do not provide updates for these external applications, we also do not test them. As such, external applications may create security vulnerabilities in our product that would not be present on a certified API Gateway appliance.

     

    I hope the above helps point you in the right direction to get telnet installed. Good luck! While I can't necessarily walk you through the entire installation since it's a third-party tool, I'll at least be here if you need some guidance.

     

    Sincerely,

     

    Dustin Dauncey

    Sr Support Engineer, Global Customer Success

    Email: Dustin.Dauncey@ca.com

    Phone: +1 800 225 5224, 48385

    Phone if outside North America: https://tinyurl.com/CAContactSupport

    CA API Management Community: https://tinyurl.com/CAAPIMCommunity

     

     



  • 3.  Re: telnet

    Broadcom Employee
    Posted Jul 26, 2018 08:17 PM

    Often telnet is used to test connectivity - here are some alternatives : 

     

    https://serverfault.com/questions/560081/check-port-open-without-telnet 

     

    In particular it was only recently I learnt about /dev/tcp 

     

    which has been really handy. 

     

    # cat < /dev/tcp/127.0.0.1/22 SSH-2.0-OpenSSH_5.3
    SSH-2.0-OpenSSH_5.3 ^C

    # cat < /dev/tcp/127.0.0.1/23
    bash: connect: Connection refused bash: /dev/tcp/127.0.0.1/23: Connection refused

     

    Cheers - Mark



  • 4.  Re: telnet

    Broadcom Employee
    Posted Jul 27, 2018 01:39 AM

    An alternation is curl command,

    curl -v telnet://target ip address:desired port number

     

    for example,

    curl -v telnet://127.0.0.1:22



  • 5.  Re: telnet

    Posted Jul 27, 2018 05:30 AM

    Hi ,

     

    You can use curl command for checking the connections.

     

    Regards,

    Grajesh



  • 6.  Re: telnet

    Posted Jul 30, 2018 10:34 AM

    Bit confused since we do not have telnet could you pick which one can be used to test connectivity to downstream hosts via APIGateway? Are you asking something below to test the connectivity instead telnet?

     

    The following is destination ip checked from gateway

    cat < /dev/tcp/192.168.181.148 :7070/22



  • 7.  Re: telnet

    Posted Jul 30, 2018 08:57 PM

    Hi Sharath,

     

    Your networking team may be more useful here as all may be a bit unique to your own environment, but in general, here are a few different ways to test connectivity from the Gateway with included tools:

     

    1. ping
    2. openssl
    3. wget or curl
    4. nslookup

     

    The three above will provide different data to you, depending on what you're looking for, and will confirm some level of a connection to the backend.

     

    I'd suggest using ping to validate that the other end is reachable on the network level. This isn't perfect though as some backends are specifically configured to not respond to basic ICMP packets, so if the backend doesn't respond back you may want to still confirm this with a second tool.

     

    I'd suggest using openssl to confirm that the backend is responding and providing the required/expected TLS certificates.

     

    If the backend is a web server, you could also use wget or curl to do an HTTP GET call to the backend, where the response will show the content of the webpage back to you in text.

     

    And finally nslookup will work well to confirm that the backend is reachable using the hostname, is resolvable to an IP address, and vice-versa.

     

    Of course, there may be more included that I'm missing right now, but those four above are probably the ones I use the most often and find the most helpful.