ನೀವು AWS Client VPN ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದ್ದೀರಿ, ಖಾಸಗಿ ಸಬ್ನೆಟ್ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಆದರೂ ಪ್ರತಿ ಸಾರ್ವಜನಿಕ ಪುಟವೂ ಸಮಯ ಮೀರಿಕೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ ಸಮಸ್ಯೆಯನ್ನು ನಿರ್ವಹಿತ ಬದಿಯ ಮೂರು ವಸ್ತುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ: ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸುವ ರೂಟ್, ಎಂಡ್ಪಾಯಿಂಟ್ನ ರೂಟ್ ಅದರ ಅಧಿಕಾರ ನಿಯಮದೊಂದಿಗೆ, ಅಥವಾ ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ನ ಮುಂದಿನ ಹಾಪ್. ನಾನು ಅವನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ವೈಫಲ್ಯವೂ ಕ್ಲೈಂಟ್ನಿಂದ ಬೇರೆ ರೀತಿ ಕಾಣುತ್ತದೆ. ಈ ಮಾರ್ಗದರ್ಶಿ VPC-ಗೆ ಸಂಬಂಧಿಸಿದ ನಿರ್ವಹಿತ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, EC2 ಇನ್ಸ್ಟಾನ್ಸ್ನಲ್ಲಿನ OpenVPN ಸರ್ವರ್ ಅನ್ನಲ್ಲ ಮತ್ತು Cloud WAN ಅಥವಾ Transit Gateway ಸಂಪರ್ಕವನ್ನಲ್ಲ.

ಕ್ಲೈಂಟ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ರೂಟ್ ಮಾಡುತ್ತದೆ ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಸಂಪರ್ಕಗೊಂಡ ಸ್ಥಿತಿ TLS ಸೆಷನ್ ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ CIDR ಹಂಚಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅಷ್ಟೇ. ಟನೆಲ್ ಮೇಲಿರುವಾಗ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗೆ ಕೇಳಿ. Linux ನಲ್ಲಿ ip route get 1.1.1.1 ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು; macOS ನಲ್ಲಿ netstat -rn -f inet | head -5 ಡೀಫಾಲ್ಟ್ ನಮೂದನ್ನು ತೋರಿಸುತ್ತದೆ; Windows ನಲ್ಲಿ Find-NetRoute -RemoteIPAddress 1.1.1.1 ಆಯ್ಕೆಯಾದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.

ನಂತರ ಸ್ಪ್ಲಿಟ್-ಟನೆಲ್ ಫ್ಲಾಗ್ ಓದಿ, ಏಕೆಂದರೆ ಎಂಡ್ಪಾಯಿಂಟ್ ಪ್ರಕಟಿಸಿದ ರೂಟ್ಗಳೇ ಕ್ಲೈಂಟ್ ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವ ಏಕೈಕ ಗಮ್ಯಸ್ಥಾನಗಳೇ ಎಂಬುದನ್ನು ಅದು ನಿರ್ಧರಿಸುತ್ತದೆ:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

ಯಾವಾಗ SplitTunnel true ಆಗಿದ್ದರೆ, ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನವು ಟನೆಲ್ ಬಳಸುವುದು ಎಂಡ್ಪಾಯಿಂಟ್ ಅದನ್ನು ಆವರಿಸುವ ರೂಟ್ ಪ್ರಕಟಿಸಿದಾಗ ಮಾತ್ರ, ಆದ್ದರಿಂದ ಕಾಣೆಯಾದ 0.0.0.0/0 ಆ ಸಂಚಾರವನ್ನು ಸ್ಥಳೀಯ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಬಿಡುತ್ತದೆ. ಅದು false ಆಗಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಆದರೆ ಎಂಡ್ಪಾಯಿಂಟ್ ಇನ್ನೂ ಅದನ್ನು ರೂಟ್ ಮಾಡಿ ಅಧಿಕಾರ ನೀಡಬೇಕು; ಇಲ್ಲದಿದ್ದರೆ ಪ್ಯಾಕೆಟ್ಗಳು ಟನೆಲ್ಗೆ ಪ್ರವೇಶಿಸಿ ಅಲ್ಲೇ ನಿಲ್ಲುತ್ತವೆ. ಎರಡರಲ್ಲಿ ಒಂದನ್ನು ಬದಲಿಸಿದ ನಂತರ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಏಕೆಂದರೆ ರೂಟ್ಗಳು ಮತ್ತು DNS ಸರ್ವರ್ಗಳು ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ನೀಡಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ತನ್ನ ಹಳೆಯ ಗುಂಪನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು.

ಎಂಡ್ಪಾಯಿಂಟ್ ರೂಟ್ ಮತ್ತು ಅಧಿಕಾರ ನಿಯಮವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಿ

ಇವು ಎರಡು ವಸ್ತುಗಳು, ಮತ್ತು ಒಂದನ್ನು ರಚಿಸುವುದು ಇನ್ನೊಂದನ್ನು ರಚಿಸುವುದಿಲ್ಲ. ಎಂಡ್ಪಾಯಿಂಟ್ ರೂಟ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಗುರಿಯು ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ ಆಗಿರುವ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಹುಡುಕಿ:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

ಪ್ರತಿ ರೂಟ್ಗೂ ನಿಖರವಾಗಿ ಒಂದು ಗುರಿ ಸಬ್ನೆಟ್ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೂರು ಸಂಯೋಜನೆಗಳಿಗೆ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಹೊಂದುವ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಬೇಕು. AWS ಈ ಕವರೇಜ್ ಅಗತ್ಯವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಕೊರತೆಯ ಪ್ರಾಯೋಗಿಕ ಲಕ್ಷಣವೆಂದರೆ ಒಂದು ಸಬ್ನೆಟ್ನಿಂದ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಿಂದ ನಿಂತುಕೊಳ್ಳುವ ಬಳಕೆದಾರ, ಇದು ಕಾಣೆಯಾದ ರೂಟ್ ಬದಲು ಮಧ್ಯೆ ಮಧ್ಯೆ ಬರುವ ದೋಷವಾಗಿ ಓದಲ್ಪಡುತ್ತದೆ. ಅಧಿಕೃತ Client VPN ಸನ್ನಿವೇಶ ದಾಖಲೆಗಳು ಈ ರೂಟ್ಗಳು ಸೇರುವ ಸಾರ್ವಜನಿಕ ಸಬ್ನೆಟ್ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಅಧಿಕಾರ ಎರಡನೇ ವಸ್ತು. ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಯಾವುದೇ ನಿಯಮ ಆವರಿಸದಿದ್ದರೆ, ಟನೆಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಹೊರುತ್ತದೆ ಮತ್ತು ಸೇವೆ ಅದನ್ನು ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಖಾಸಗಿ ಸಂಪನ್ಮೂಲಗಳು ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತವೆ, ಇಂಟರ್ನೆಟ್ ಮಾತ್ರ ಇಲ್ಲ:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC CIDR ಗಾಗಿ ನಿಯಮವು 0.0.0.0/0 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಪೂರ್ಣ ಟನೆಲ್ಗೆ ಕಾಣೆಯಾದ ಭಾಗಗಳನ್ನು ಸೇರಿಸುವುದು ಎಂದರೆ ಪ್ರತಿ ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ಗೂ ಒಂದು ರೂಟ್ ಜೊತೆಗೆ ನಂತರ ಪರಿಶೀಲಿಸಬಹುದಾದ ಅಧಿಕಾರ ನಿಯಮ:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all ಎಂಡ್ಪಾಯಿಂಟ್ನ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೂ ಗಮ್ಯಸ್ಥಾನವನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಪೂರ್ಣವಾಗಿರಬೇಕಾದಷ್ಟು ಕಾಲ ಮಾತ್ರ ಅದನ್ನು ಇರಿಸಿ; ಬಂಧಿಸಲು ಗುಂಪುಗಳಿದ್ದರೆ ಡೈರೆಕ್ಟರಿ ಗುಂಪಿಗೆ ಬಂಧಿಸಿದ ನಿಯಮ ಉತ್ತಮ.

ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ನಿಂದ ಹೊರಗೆ ಅನುಸರಿಸಿ

ಎಂಡ್ಪಾಯಿಂಟ್ ರೂಟ್, AWS ಆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಆ ಸಬ್ನೆಟ್ಗೆ ನೀಡುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದರ ನಂತರದ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಅದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ, ಅದು ಸಬ್ನೆಟ್ನ ಸ್ವಂತ VPC ರೂಟ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಇರುತ್ತದೆ:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

ಬಳಸಬಹುದಾದ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಸಾರ್ವಜನಿಕ ಸಬ್ನೆಟ್ಗೆ ಇಂಟರ್ನೆಟ್ ಗೇಟ್ವೇ ಕಡೆಗೆ, ಅಥವಾ ಖಾಸಗಿ ಸಬ್ನೆಟ್ಗೆ NAT ಗೇಟ್ವೇ ಕಡೆಗೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು blackhole ಸ್ಥಿತಿ ಎಂದರೆ ಗುರಿಯನ್ನು ಅಳಿಸಲಾಗಿದೆ ಮತ್ತು ಮಾರ್ಗ ಈಗ ಸದ್ದಿಲ್ಲದೆ ಸಾಯುತ್ತಿದೆ. ಇವು ಎಂಡ್ಪಾಯಿಂಟ್ನ ರೂಟ್ ಪಟ್ಟಿಗಿಂತ ಬೇರೆ ಕೋಷ್ಟಕಗಳು, ಮತ್ತು ಒಂದನ್ನು ಸರಿಪಡಿಸುವುದು ಇನ್ನೊಂದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಈ ಹಾಪ್ನಲ್ಲಿ ಎರಡು ಫಿಲ್ಟರ್ಗಳಿವೆ. ಗುರಿ ನೆಟ್ವರ್ಕ್ ಸಂಯೋಜನೆಗೆ ಅನ್ವಯಿಸಿದ ಭದ್ರತಾ ಗುಂಪು ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನದ ಕಡೆಗೆ ಹೊರಹೋಗುವ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡಬೇಕು, ಮತ್ತು ಅನ್ವಯವಾಗುವ ಯಾವುದೇ ನೆಟ್ವರ್ಕ್ ACL ವಿನಂತಿ ಮತ್ತು ಎಫೆಮೆರಲ್ ಪೋರ್ಟ್ಗಳ ಮೇಲಿನ ಹಿಂತಿರುಗುವ ಸಂಚಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡಬೇಕು. ನಿರ್ಬಂಧಕ ಸಂಯೋಜನೆ ಭದ್ರತಾ ಗುಂಪು ಖಾಸಗಿ ಪ್ರವೇಶ ಕೆಲಸ ಮಾಡಿ ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶ ಮಾಡದಿರುವ ಸಾಮಾನ್ಯ ಕಾರಣ.

ಮೂರನ್ನೂ ಒಟ್ಟಿಗೆ ಬದಲಿಸುವ ಬದಲು ಲಕ್ಷಣದಿಂದ ಮೊದಲ ಪದರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

DNS ವೈಫಲ್ಯವನ್ನು ಸತ್ತ ರೂಟ್ನಿಂದ ಬೇರ್ಪಡಿಸಿ

ಹೆಸರು ವಿಭಜನೆ ಫಾರ್ವರ್ಡಿಂಗ್ಗಿಂತ ಬೇರೆ ರೀತಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಪೂರ್ಣ ಟನೆಲ್ ಈ ವ್ಯತ್ಯಾಸವನ್ನು ಮುಖ್ಯವಾಗಿಸುತ್ತದೆ ಏಕೆಂದರೆ ತಳ್ಳಲಾದ ರಿಸಾಲ್ವರ್ ಈಗ ಟನೆಲ್ ಮೂಲಕ ತಲುಪುತ್ತದೆ. ಎಂಡ್ಪಾಯಿಂಟ್ VPC DNS ಸರ್ವರ್ಗಳನ್ನು ಸೂಚಿಸಿದರೆ, ಅವುಗಳ ವಿಳಾಸಗಳಿಗೆ ಇತರ ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನದಂತೆ ರೂಟ್ ಕವರೇಜ್ ಮತ್ತು ಅಧಿಕಾರ ಬೇಕು. ಯಾವ ವೈಫಲ್ಯವಿದೆ ಎಂದು ನೋಡಲು ರಿಸಾಲ್ವರ್ ಅನ್ನು ನೇರವಾಗಿ ಕೇಳಿ: dig +short example.com @10.0.0.2, ಅಥವಾ nslookup example.com 10.0.0.2 Windows ನಲ್ಲಿ.

ಸಂಖ್ಯಾತ್ಮಕ URL ಉತ್ತರಿಸಿ ಹೆಸರಿನ URL ಉತ್ತರಿಸದಿದ್ದಾಗ, ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಸಂಪಾದನೆಯನ್ನು ನಿಲ್ಲಿಸಿ DNS ಮೇಲೆ ಕೆಲಸ ಮಾಡಿ. IP ವಿಳಾಸಕ್ಕೆ ವಿನಂತಿ ಹೆಸರಿನ ವರ್ಚುವಲ್ ಹೋಸ್ಟ್ ಮತ್ತು ಅದರ ಪ್ರಮಾಣಪತ್ರದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅಂತಿಮ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಒಂದು ಹೆಸರಿನ ಪರೀಕ್ಷೆಯನ್ನು ಇರಿಸಿ.

ಸಮಯ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕೆಲವು ಸೆಕೆಂಡುಗಳில் ಉತ್ತರ ಬಾರದ TCP ಸಂಪರ್ಕ ರೂಟಿಂಗ್ ಅಥವಾ ಫಿಲ್ಟರ್ ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಹೆಸರು ಹುಡುಕಾಟದಲ್ಲಿ ನೇತಾಡುವ ವಿನಂತಿ ರಿಸಾಲ್ವರ್ ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ. ರಿಸಾಲ್ವರ್ ತಲುಪಲಾಗದಿರುವಾಗ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಬದಲಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ವೈಫಲ್ಯವನ್ನು ಎರಡಾಗಿಸುತ್ತದೆ.

ಸ್ವಚ್ಛವಾಗಿ ಹಿಂತಿರುಗಿಸಿ, ನಂತರ ಎಗ್ರೆಸ್ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಎರಡೂ ವಸ್ತುಗಳು ಸಂಕಲನಾತ್ಮಕವಾಗಿದ್ದವು, ಆದ್ದರಿಂದ ಹಿಂತಿರುಗಿಸುವುದು ಸರಿಪಡಿಸುವುದಲ್ಲ, ಅಳಿಸುವುದು:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಸಂಚಾರ ಯಾವ ಮಾರ್ಗದಿಂದ ಹೊರಬರುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಗಮನಿಸಿದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು NAT ಗೇಟ್ವೇಯ ಸ್ಥಿತಿಸ್ಥಾಪಕ IP ವಿಳಾಸದೊಂದಿಗೆ, ಅಥವಾ ನೀವು ಬಳಸಲು ಉದ್ದೇಶಿಸಿದ್ದ ಇಂಟರ್ನೆಟ್ ಗೇಟ್ವೇಯೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಖಾಸಗಿ ಸಂಪನ್ಮೂಲವು ಅದೇ ಅಧಿವೇಶನದಲ್ಲಿ ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.

ಸಣ್ಣ ಪಟ್ಟಿಯೊಂದಿಗೆ ಮುಗಿಸಿ ಮತ್ತು ಕೊನೆಯ ಅಂಶವನ್ನು ದಾಖಲಾತಿಯಲ್ಲ, ಬದಲಾವಣೆಯ ಭಾಗವಾಗಿ ಪರಿಗಣಿಸಿ:

  • ಪ್ರತಿ ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ಗೂ ಒಂದು 0.0.0.0/0 ಎಂಡ್ಪಾಯಿಂಟ್ ರೂಟ್.
  • ನೀವು ಸೇವೆ ನೀಡಲು ಬಯಸುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ 0.0.0.0/0 ಆವರಿಸುವ ಅಧಿಕಾರ ನಿಯಮ.
  • ಪ್ರತಿ ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ನಲ್ಲಿ blackhole ಅಲ್ಲದ VPC ಡೀಫಾಲ್ಟ್ ರೂಟ್.
  • ಸಂಯೋಜನೆ ಭದ್ರತಾ ಗುಂಪಿನ ಎಗ್ರೆಸ್, ಜೊತೆಗೆ ACL ಹಿಂತಿರುಗುವ ಸಂಚಾರ.
  • ರಿಸಾಲ್ವರ್ ವಿಳಾಸಗಳು ರೂಟ್ ಮತ್ತು ಅಧಿಕೃತಗೊಂಡಿವೆ, ಹೆಸರಿನ ವಿನಂತಿಯಿಂದ ಪರಿಶೀಲಿಸಲಾಗಿದೆ.
  • ರೂಟ್ ಮತ್ತು ನಿಯಮಕ್ಕಾಗಿ ದಾಖಲಾದ ರೋಲ್ಬ್ಯಾಕ್.

ಒಂದು ವ್ಯಾಪ್ತಿ ಟಿಪ್ಪಣಿ: ಇದು IPv4 ಮಾರ್ಗ. ದ್ವಿ-ಸ್ಟ್ಯಾಕ್ ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಇರುವ IPv6 ಸಂಪರ್ಕವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ IPv6 ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಇದರ ಅಡ್ಡಪರಿಣಾಮವಲ್ಲ, ತನ್ನದೇ ಅಧಿಕಾರವಿರುವ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು