peered VPC ತಲುಪಲು AWS Client VPN ಅಥವಾ bastion
ಎರಡೂ ಮಾರ್ಗಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಆದರೆ ಬೇರೆ ಬೇರೆ ಕಡೆ ಮುರಿಯುತ್ತವೆ. endpoint ಮಾರ್ಗಗಳು, ರಿಟರ್ನ್ ರೂಟಿಂಗ್ ಮತ್ತು bastion ಪ್ರಾಮಾಣಿಕ ಗಡಿಯಾಗಿರುವ ಮೂರು ಸಂದರ್ಭಗಳನ್ನು ಹೋಲಿಸಿ.
ಒಂದು Client VPN endpoint ತನ್ನ ಸಂಬಂಧಿತ VPC ಜೊತೆ peered ಆಗಿರುವ VPC ತಲುಪಬಹುದು, ಮತ್ತು ಅದನ್ನು ಕಾನೂನುಬದ್ಧಗೊಳಿಸಲು ನಿಮಗೆ bastion ಬೇಕಿಲ್ಲ. ಮಾಡಲು ಯೋಗ್ಯವಾದ ಆಯ್ಕೆ ಎಂದರೆ ಸಂಚಾರ ಎಲ್ಲಿ ಕೈ ಬದಲಾಯಿಸುತ್ತದೆ ಎಂಬುದು: association ಸಬ್ನೆಟ್‌ನಲ್ಲಿ ಇಳಿಯುವ ಮತ್ತು peering ಸಂಪರ್ಕವನ್ನು ದಾಟುವ endpoint ಮಾರ್ಗ, ಅಥವಾ peered VPC ಯಲ್ಲಿ ಸೆಷನ್ ಕೊನೆಗೊಳಿಸುವ host. ಎರಡೂ ಮಾರ್ಗಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಬೇರೆ ಬೇರೆ ಕಡೆ ವಿಫಲವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿರ್ಧಾರ ಮಾಲೀಕತ್ವ ಮತ್ತು ಆಡಿಟ್ ಬಗ್ಗೆ, AWS ಏನು ಅನುಮತಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅಲ್ಲ. ಅವುಗಳ ನಡುವೆ ನಾನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುತ್ತೇನೆ ಮತ್ತು routed ಮಾರ್ಗವನ್ನು ಕೆಲಸ ಮಾಡಿಸುವ ನಾಲ್ಕು ನಮೂದುಗಳು ಇಲ್ಲಿವೆ.
ಎರಡು ಮಾರ್ಗ, ಒಂದು endpoint, ಬೇರೆ ಬೇರೆ ಮಾಲೀಕರು
routed ಮಾರ್ಗದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಸಂಚಾರ endpoint ತಲುಪುತ್ತದೆ, association ಸಬ್ನೆಟ್‌ನಲ್ಲಿನ Client VPN ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು A ಯಿಂದ B ಗೆ peering ಸಂಪರ್ಕದ ಮೂಲಕ ಆ ಸಬ್ನೆಟ್ ಬಿಡುತ್ತದೆ. VPC B ಯಾವುದೇ VPN ಸೆಷನ್ ಕೊನೆಗೊಳಿಸುವುದಿಲ್ಲ; ಅದು VPC A ಯಿಂದ ಸಾಮಾನ್ಯ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ರಿಟರ್ನ್ ಮಾರ್ಗ ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಅಲ್ಲ, VPC A ಗೆ ತೋರಿಸುತ್ತದೆ.
bastion ಮಾರ್ಗದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಮೊದಲು host ತಲುಪುತ್ತದೆ. A ಯಲ್ಲಿನ bastion ಕೊನೆಯ ಹಾಪ್ ಅನ್ನು ಇನ್ನೂ peering ಸಂಪರ್ಕದ ಮೂಲಕ ಹೋಗಲು ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ peering ಕೆಲಸ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಒಂದು ಸೆಷನ್ ಸೇರುತ್ತದೆ. B ಯಲ್ಲಿನ bastion ಗೂ ಕ್ಲೈಂಟ್‌ನಿಂದ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಆ ಮಾರ್ಗ ಅದೇ endpoint ಮಾರ್ಗವಾದರೆ, routed ವಿನ್ಯಾಸಕ್ಕೆ ಒಂದು ಹಾಪ್ ಸೇರುತ್ತದೆ. bastion ಕೆಲಸ ಕಡಿಮೆ ಮಾಡುವುದು ಅದು ಈಗಾಗಲೇ ಇದ್ದಾಗ, ಈಗಾಗಲೇ ಅನುಮೋದಿತವಾದಾಗ, ಮತ್ತು ಅದರ ಹಿಂದಿನ ವಸ್ತುವಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಗಡಿಯ ಬದಲು ಸೆಷನ್ ಗಡಿ ಬೇಕಾದಾಗ ಮಾತ್ರ.
ನಾಲ್ಕು ನಮೂದುಗಳು routed ಮಾರ್ಗವನ್ನು ಕೆಲಸ ಮಾಡಿಸುತ್ತವೆ
AWS ಈ ಸನ್ನಿವೇಶವನ್ನು Client VPN how-it-works ಪುಟದಲ್ಲಿ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಎರಡು ಅಥವಾ ಮೂರು ತಂಡಗಳ ಒಡೆತನದ ನಾಲ್ಕು ನಮೂದುಗಳಿಗೆ ಬರುತ್ತದೆ. ಶ್ರೇಣಿಗಳು ಉದಾಹರಣೆಗಾಗಿ; peered ಶ್ರೇಣಿ ಅನನ್ಯವಾಗಿರಬೇಕು ಮತ್ತು ರಿಟರ್ನ್ ಶ್ರೇಣಿ ನಿಮ್ಮ ಯೋಜನೆಗೆ ಹೊಂದಬೇಕು.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
ಮಾರ್ಗ ಮತ್ತು ಅನುಮತಿ ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣಗಳು. ಹೊಂದಿಕೆಯಾಗುವ ಅಧಿಕಾರ ನಿಯಮವಿಲ್ಲದ ಸರಿಯಾದ endpoint ಮಾರ್ಗ ಕ್ಲೈಂಟ್‌ಗೆ ಏನನ್ನೂ ಕೊಡುವುದಿಲ್ಲ; endpoint ಮಾರ್ಗ ಮಾಡಲಾಗದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಅಧಿಕಾರ ನಿಯಮ ಅದಕ್ಕೆ ಕಪ್ಪು ಕುಳಿ ಕೊಡುತ್ತದೆ. ಎರಡೂ ಒಂದೇ ಶ್ರೇಣಿಯನ್ನು ಹೆಸರಿಸಬೇಕು.
endpoint ಮಾರ್ಗ endpoint ನದೇ VPC ಯಲ್ಲಿನ ಸಬ್ನೆಟ್‌ಗೆ ತೋರಿಸುತ್ತದೆ, ಎಂದಿಗೂ peering ಸಂಪರ್ಕಕ್ಕೆ ಅಲ್ಲ. VPC ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು peering ಸಂಪರ್ಕಕ್ಕೆ ತೋರಿಸುತ್ತವೆ, ಎಂದಿಗೂ instance ಅಥವಾ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಅಲ್ಲ. ಎರಡರ ನಡುವೆ ಮೌಲ್ಯವನ್ನು ನಕಲಿಸುವುದು ದೂರಿಲ್ಲದೆ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ಮಾರ್ಗ ಮಾಡುವುದಿಲ್ಲ.
association ಸಬ್ನೆಟ್ ಕ್ಲೈಂಟ್ ಮೂಲವನ್ನು ಅನುವಾದಿಸುವುದರಿಂದ, B ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಅಲ್ಲ, VPC A ಗೆ ಹಿಂತಿರುಗಿ ಮಾರ್ಗ ಮಾಡಬೇಕು. ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಯನ್ನು peering ಸಂಪರ್ಕದ ಮೇಲೆ ಕಳುಹಿಸುವುದು ಸಮಮಿತಿಯಂತೆ ಕಾಣುತ್ತದೆ, ಪರಿಶೀಲನೆ ದಾಟುತ್ತದೆ ಮತ್ತು ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ ಏಕೆಂದರೆ B ಎಂದಿಗೂ ಕ್ಲೈಂಟ್ ಮೂಲವಿರುವ ಪ್ಯಾಕೆಟ್ ನೋಡುವುದಿಲ್ಲ.
ಸುರಕ್ಷತಾ ಗುಂಪುಗಳು ಮತ್ತು ಅನುಮತಿಯ ಕೊನೆಯ ಮೀಟರ್
ಮಾರ್ಗನಿರ್ದೇಶನ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು B ಗೆ ತರುತ್ತದೆ; B ಇನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದೇ ಪ್ರದೇಶದ ಸಕ್ರಿಯ peering ಸಂಪರ್ಕಕ್ಕೆ, B ಯಲ್ಲಿನ ಸುರಕ್ಷತಾ ಗುಂಪು Client VPN association ಗೆ ಅನ್ವಯಿಸಿದ ಗುಂಪನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು, ಇದು ನಿಯಮವನ್ನು ಸಂಕುಚಿತವಾಗಿ ಇಡುತ್ತದೆ ಮತ್ತು ವಿಳಾಸ ಬದಲಾವಣೆಗಳನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತದೆ. ಗುಂಪು ಉಲ್ಲೇಖ ಸಾಧ್ಯವಿಲ್ಲದಲ್ಲಿ, 0.0.0.0/0 ಗೆ ವಿಸ್ತರಿಸುವ ಬದಲು association ಸಬ್ನೆಟ್ ಶ್ರೇಣಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮತಿಸಿ, ಏಕೆಂದರೆ ಅದು ಮಾರ್ಗನಿರ್ದೇಶನ ದೋಷವನ್ನು ವಿವರಣೆ ಇಲ್ಲದ ಟೈಮೌಟ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.
ನಂತರ ಮಾರ್ಗನಿರ್ದೇಶನ ಎಂದಿಗೂ ಮುಟ್ಟದ್ದನ್ನು ಪರಿಶೀಲಿಸಿ: ಎರಡೂ ಸಬ್ನೆಟ್‌ಗಳ ನೆಟ್‌ವರ್ಕ್ ACL, ಅಪ್ಲಿಕೇಶನ್‌ನ allow-list ಅಥವಾ ಟೋಕನ್ ಪ್ರೇಕ್ಷಕರು, ಮತ್ತು DNS. peering ಖಾಸಗಿ ಹೋಸ್ಟೆಡ್ ವಲಯಗಳನ್ನು ನಕಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಲ್ಯಾಪ್‌ಟಾಪ್ ಪರಿಹರಿಸಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬಹುದು, ಮತ್ತು peering ಸಂಪರ್ಕ ಪ್ರಮಾಣಪತ್ರಕ್ಕೆ ಯಾವುದೇ ವಿಶ್ವಾಸ ಸೇರಿಸುವುದಿಲ್ಲ. endpoint ಅನ್ನು B ಗೆ ಉತ್ತರಿಸುವ resolver ಗೆ ತೋರಿಸಿ, ನಂತರ ಖಾಸಗಿ ಹೆಸರು ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಹೊಂದುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
bastion ಪ್ರಾಮಾಣಿಕ ಉತ್ತರವಾಗುವ ಸಂದರ್ಭ
ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ bastion ಆಯ್ಕೆ ಮಾಡಲು ನಾನು ಮೂರು ಪ್ರಚೋದಕಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತೇನೆ. peered VPC ನಿಮ್ಮ ಶ್ರೇಣಿಗೆ ರಿಟರ್ನ್ ಮಾರ್ಗ ಸೇರಿಸದ ಅಥವಾ ಗುಂಪು ಉಲ್ಲೇಖ ಸ್ವೀಕರಿಸದ ತಂಡದ್ದು. ಪ್ರವೇಶವನ್ನು ಪ್ರತಿ ಸೆಷನ್‌ಗೆ ಅನುಮೋದಿಸಬೇಕು ಅಥವಾ ದಾಖಲಿಸಬೇಕು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ತಾನೇ ಹೊರಲಾರದು. ಅಥವಾ ಕೊನೆಯ ಹಾಪ್ B ಒಳಗೆ ಉಳಿಯಬೇಕು ಏಕೆಂದರೆ ಸೇವೆ ಅಲ್ಲಿಯೇ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಅದರ TLS ಗುರುತು ಆಂತರಿಕ ಹೆಸರಿಗೆ ಪಿನ್ ಆಗಿದೆ.
ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ peering ಪ್ರವೇಶಾತ್ಮಕವಲ್ಲ ಎಂಬ ಅಂಶವನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಅಪ್ರವೇಶಾತ್ಮಕತೆ B ಯ ಸಂಪನ್ಮೂಲಗಳು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ: ಅವು A ಯೊಂದಿಗೆ peered ಆಗಿರುವ ಮೂರನೇ VPC ಗೆ A ಅನ್ನು ಟ್ರಾನ್ಸಿಟ್ ಆಗಿ ಬಳಸಲಾರವು. VPN ಬಳಕೆದಾರ ನೇರವಾಗಿ peered VPC ತಲುಪಲಾರ ಎಂದು ಅದು ಎಂದಿಗೂ ಅರ್ಥವಲ್ಲ, ಮತ್ತು ಆ ತಪ್ಪು ಓದುವಿಕೆಯನ್ನು ತಪ್ಪಿಸಲು ನಿರ್ಮಿಸಿದ bastion ಕಾರಣವಿಲ್ಲದೆ ಪ್ಯಾಚ್ ಮಾಡುವ host.
ವಿರುದ್ಧ ತಪ್ಪು ಕಾಲಾನಂತರದಲ್ಲಿ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ: ಈಗಾಗಲೇ ಇರುವ ಒಂದೇ bastion ಮೂಲಕ ಪ್ರತಿ ತಂಡವನ್ನೂ ಹಾಯಿಸಿ, ನಂತರ ಅದರ ಸುರಕ್ಷತಾ ಗುಂಪು, ಮಾರ್ಗ ಕೋಷ್ಟಕ ಮತ್ತು ಪ್ಯಾಚ್ ವಿಂಡೋ ಉತ್ಪಾದನಾ ಅವಲಂಬನೆ ಎಂದು ಕಂಡುಕೊಳ್ಳಿ. host ಯಾವ ಪ್ರಚೋದಕಕ್ಕೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ, ಮತ್ತು ಪ್ರಚೋದಕ ಹೋದಾಗ ಅದನ್ನು ನಿವೃತ್ತಿಗೊಳಿಸಿ.
Transit Gateway ಮತ್ತು ಹಲವು association ಗಣನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ
endpoint ಸಬ್ನೆಟ್‌ಗೆ ಬದಲು ನೇರವಾಗಿ Transit Gateway ಗೆ ಜೋಡಣೆಯಾಗಿದ್ದರೆ, ಮಾದರಿ ಬದಲಾಗುತ್ತದೆ: ಕ್ಲೈಂಟ್‌ಗಳು ಇನ್ನು association ಸಬ್ನೆಟ್‌ನ ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು gateway ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿ ಜೊತೆಗೆ peered VPC ಗೆ ಕರೆದೊಯ್ಯುವ ಜೋಡಣೆಯನ್ನೂ ಹೊರಬೇಕು. ಇದು ಪ್ರಮಾಣದಲ್ಲಿ ಸ್ವಚ್ಛವಾಗಿದೆ, ಆದರೆ ಕೆಲಸ ನಾಲ್ಕು ನಮೂದುಗಳಿಂದ gateway ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳಿಗೆ ಸರಿಯುತ್ತದೆ.
ಹಲವು association ಪರಿಶೀಲನೆಗಳನ್ನು ಗುಣಿಸುತ್ತವೆ. endpoint ಮಾರ್ಗ endpoint ನದು, ಆದರೂ ಪ್ರತಿ association ಸಬ್ನೆಟ್‌ಗೆ ನಿಜವಾದ peering ಮುಂದಿನ ಹಾಪ್ ಇರುವ ಮಾರ್ಗ ಕೋಷ್ಟಕ ಬೇಕು. ಒಂದು association ಮೂಲಕ ಸೆಷನ್ ಯಶಸ್ವಿಯಾಗಬಹುದು, ಇನ್ನೊಂದಕ್ಕೆ ರಿಟರ್ನ್ ಮಾರ್ಗ ಇಲ್ಲದಿರಬಹುದು, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದನ್ನೂ ಪರೀಕ್ಷಿಸಿ.
ಮುರಿತವನ್ನು ಬೇಗ ಕಂಡುಹಿಡಿಯುವ ಪರಿಶೀಲನಾ ಕ್ರಮ
ಇವನ್ನು ಕ್ರಮವಾಗಿ ನಡೆಸಿ; ಪ್ರತಿ ಹಂತವೂ ಮುಂದಿನದು ವಿಫಲವಾಗುವಾಗ ಪಾಸಾಗಬಹುದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಟೈಮೌಟ್ ಯಾವುದು ಮುರಿದಿತು ಎಂದು ಬಹುತೇಕ ಹೇಳುವುದಿಲ್ಲ.
- ಕ್ಲೈಂಟ್‌ನಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ ಮತ್ತು ವಿಳಾಸ peered ಶ್ರೇಣಿಯ ಒಳಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
- ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಸೆಷನ್ ಕೊನೆಗೊಳಿಸಿದ association ಗಾಗಿ endpoint ಸಂಪರ್ಕ ಲಾಗ್ ಓದಿ.
- ಆ association ಸಬ್ನೆಟ್‌ನಲ್ಲಿ, ಮಾರ್ಗ ಕೋಷ್ಟಕ peered ಶ್ರೇಣಿಯನ್ನು ಸಕ್ರಿಯ peering ಸಂಪರ್ಕಕ್ಕೆ ತೋರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
- B ಯ ಸಂಪನ್ಮೂಲ ಸಬ್ನೆಟ್‌ನಲ್ಲಿ, ಇಂಟರ್‌ಫೇಸ್ ಶ್ರೇಣಿಯ ರಿಟರ್ನ್ ನಮೂದು ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ ಗುಂಪು ನಿಯಮಗಳನ್ನು ಖಚಿತಪಡಿಸಿ.
- ಒಂದು ಅನುಮತಿಸಿದ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು ತಲುಪಲಾಗದೇ ಇರಬೇಕಾದ ಒಂದು ಸಂಪನ್ಮೂಲವನ್ನು ಪರೀಕ್ಷಿಸಿ; ಎರಡನೆಯದು ಡೀಬಗ್ ಉಳಿಕೆಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ.
- ಯಾವುದೇ split-tunnel ಮಾರ್ಗ ಬದಲಾವಣೆಯ ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಏಕೆಂದರೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಟನೆಲ್ ಹೊಸ ಮಾರ್ಗ ಸೆಟ್ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ.
ನೆನಪಿಡಲು ಯೋಗ್ಯವಾದ ಎರಡು ಲಕ್ಷಣಗಳಿವೆ. ಉತ್ತರವಿಲ್ಲದೆ B ತಲುಪುವ SYN ಬಹುತೇಕ ಯಾವಾಗಲೂ ಕಾಣೆಯಾದ ರಿಟರ್ನ್ ಮಾರ್ಗ. ಪೂರ್ಣಗೊಂಡು ನಂತರ ಮರುಹೊಂದಿಸುವ ಸಂಪರ್ಕ ಸಾಮಾನ್ಯವಾಗಿ ಗುಂಪು, ACL ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್. ಎರಡೂ endpoint ಲಾಗ್‌ನಲ್ಲಿ ಕಾರಣವಾಗಿ ಕಾಣುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾಲ್ಕು ನಮೂದುಗಳನ್ನು ಪ್ರತಿಯೊಂದರ ಪಕ್ಕದಲ್ಲಿ ಮಾಲೀಕರೊಂದಿಗೆ ಇಡಿ.
ಮೂರು ಪ್ರಚೋದಕಗಳಲ್ಲಿ ಯಾವುದೂ ಅನ್ವಯಿಸದಿದ್ದರೆ, routed ಮಾರ್ಗವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ ಆ ನಾಲ್ಕು ನಮೂದುಗಳನ್ನು ದಾಖಲಿಸಿ. ಒಂದು ಅನ್ವಯಿಸಿದರೆ, bastion ಅನ್ನು ಆ ಗಡಿಗೆ ಮಾತ್ರ ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಮುಂದೆ ಸೆಷನ್ ಬೇಕಿಲ್ಲದ ಸೇವೆಗಳಿಗೆ endpoint ಮಾರ್ಗವನ್ನು ಬಿಡಿ.