- 최신
- 최다 투표
- 가장 많은 댓글
The experiment works on your local physical LAN, as you don't apply microsegmentation. Every interface of instances on your VPC subnet has a security group, which enforces stateful microsegmentation (e.g. an incoming rule is created automatically when outgoing TCP session starts)[1] When you trying to access over network, you need to confirm that the protocols and ports are enabled in Security Group settings in the VPC. Additionally, check the NACL - network access control list, that operate in subnet level and are stateless (you need to define rules to allow communication in both incoming and outgoing directions)
References:
[1] https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
[2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
Thank you, Vlad. I will review the references. may I ask to possible explain the following:
-
A simple console C/C+ directory listing app can access the remote symbolic link folder items.
-
A backend p-code XYZ app run at the console level can also access the remote symbolic link items. THis would be a C/C++ app running a p-code app with an RTE engine. Pretty much like a C/C++ run time engine running a php, or python job.
-
A web-based hosting server with the same RTE that runs the XYZ backend p-code app, can not access the remote symbolic link items. This would be a single process web server spawning client threads to process HTTP requests.
-
Same as #3, perform at home non-AWS LAN, it works fine.
All is running in Administrator level.
If #1 and #2 works but #3 does not, the only diff are the layers of API piping that is governing the I/O. But this additional layer with #4 is fine on a non-AWS network. Is this a Windows OS issue? or still something related to AWS? Or both?
Thanks for your input , I will review the references.
Solution found:
This is not a AWS issue, but rather a Windows Service network security issue with Directory Symbolic Links. Running the file server application as a Windows Desktop allowed access to the remote symbolic link directory items. But not when running as Windows service (formerly called NT Service). When the service login credentials were changed to authenticated user with network access, the remote symbolic link directory items were accessible.