ಸೈಟ್-ಟು-ಸೈಟ್ VPN ನಾದ್ಯಂತ IPv6 ಪ್ರಿಫಿಕ್ಸ್ ನಿಯೋಗ: ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಟನೆಲ್ ಎತ್ತುವುದು ಸುಲಭದ ಅರ್ಧ. ಸೈಟ್-ಟು-ಸೈಟ್ ಲಿಂಕ್ ದಿನಗಟ್ಟಲೆ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೂ ದೂರದ LAN ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಹೋಸ್ಟ್ ಮೌನವನ್ನೇ ಹಿಂತಿರುಗಿಸುತ್ತಿದ್ದುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ, ಏಕೆಂದರೆ ಆ ಗೇಟ್ವೇಯ ಹಿಂದಿನ ನಿಯೋಗಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸಂರಚಿಸಲಾಗಿತ್ತು ಆದರೆ ಎಂದಿಗೂ ಟನೆಲ್ಗೆ ರೂಟ್ ಆಗಿರಲಿಲ್ಲ. ಟನೆಲ್ ವಿಳಾಸಗಳು ಆ ಸಮಯದಲ್ಲೆಲ್ಲಾ ಪಿಂಗ್ಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತಿದ್ದವು, ಮತ್ತು ಅದೇ ಕಾರಣದಿಂದ ಯಾರೂ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ನೋಡಲಿಲ್ಲ. ನಿಯೋಗಿಸಿದ IPv6 ಪ್ರಿಫಿಕ್ಸ್ ಸೈಟ್ VPN ಅನ್ನು ದಾಟಬೇಕಾದಾಗ ನಾನು ಪರಿಶೀಲಿಸುವ ಕ್ರಮ ಇದು: ಪ್ರಿಫಿಕ್ಸ್ ನಕ್ಷೆ, ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ಗಳು, ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು firewall, ನಂತರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ.

ಟನೆಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಪ್ರಿಫಿಕ್ಸ್ ನಕ್ಷೆ ಬರೆಯಿರಿ

ಪ್ರಿಫಿಕ್ಸ್ ನಿಯೋಗವು ಕೇಳಿದ ರೂಟರ್ಗೆ ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ಅದು ಪಿಯರ್ನಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಆ ಬ್ಲಾಕ್ ಅನ್ನು on-link ಆಗಿ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕೇಳುವ ರೂಟರ್ನ ಹಿಂದೆ ಏನಿದೆ ಎಂದು ದೂರದ ಗೇಟ್ವೇಗೆ ಹೇಳುವುದಿಲ್ಲ. ಈ ಮೂರನ್ನು ನೀವೇ ಸಂರಚಿಸಬೇಕು, ಮತ್ತು ಯಾವುದೇ ಕಾನ್ಫಿಗ್ ಫೈಲ್ ಬದಲಾಗುವ ಮೊದಲು ಅವು ವಿಳಾಸ ಯೋಜನೆಯಲ್ಲಿ ಇರಬೇಕು.

ಪ್ರತಿ ಸೈಟ್ಗೂ ನಿಯೋಗಿಸಿದ ಪ್ರಿಫಿಕ್ಸ್, LAN ನಲ್ಲಿ ನಿಜವಾಗಿ ಬಳಸುವ /64, ಟನೆಲ್ ವಿಳಾಸಗಳು ಮತ್ತು ಪ್ರತಿ ಮಾರ್ಗದ ಮಾಲೀಕರನ್ನು ದಾಖಲಿಸಿ. ಪೂರೈಕೆದಾರರು ಸೈಟ್ A ಗೆ 2001:db8:a1::/56 ಅನ್ನು ನಿಯೋಗಿಸುತ್ತಾರೆ, ಅದು ತನ್ನ LAN ನಲ್ಲಿ 2001:db8:a1:10::/64 ಅನ್ನು ಪೂರೈಸುತ್ತದೆ; ಸೈಟ್ B 2001:db8:b2::/64 ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಸೈಟ್ A ಆ ಒಂದು /64 ಅನ್ನು ಮಾತ್ರ ಪೂರೈಸಿದರೆ, ಎರಡೂ ತುದಿಗಳು ಇಡೀ /56 ಬದಲು 2001:db8:a1:10::/64 ಅನ್ನು ಹೆಸರಿಸಬೇಕು.

ಬಹುತೇಕ ಪ್ರತಿ ಬಾರಿಯೂ ಎರಡು ತಪ್ಪುಗಳು ಕಾಣಿಸುತ್ತವೆ. ಒಂದು ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು on-link ಎಂದು ಪರಿಗಣಿಸುವುದು, ಅದನ್ನು ಬ್ರಿಡ್ಜ್ ಮಾಡುವುದು ಅಥವಾ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಇಡುವುದು, ಹೀಗಾಗಿ ಗೇಟ್ವೇ ತಲುಪಲಾಗದ ಹೋಸ್ಟ್ಗಳಿಗೆ ನೆರೆಹೊರೆಯ ಕೋರಿಕೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಇನ್ನೊಂದು ಒಂದೇ /64 ಸಂರಚಿಸಿದಾಗ ಇಡೀ /56 ಅನ್ನು ಜಾಹೀರಾತು ಮಾಡುವುದು: ಮಾರ್ಗ ಕೋಷ್ಟಕವು ಬ್ಲಾಕ್ ತಲುಪಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ವಿಳಾಸಗಳು ಕಪ್ಪು ಕುಳಿಗೆ ಬೀಳುತ್ತವೆ.

ಎರಡೂ ತುದಿಗಳ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಮಾರ್ಗಗಳಿಗೆ ಹೊಂದಿಸಿ

IKEv2 ಮತ್ತು WireGuard ಎರಡೂ ಹೊಂದಿಸದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತವೆ, ಟನೆಲ್ ಇನ್ನೂ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುವಷ್ಟು ಮೌನವಾಗಿ.

strongSwan ನಲ್ಲಿ ಸೆಲೆಕ್ಟರ್ಗಳು ಸ್ಪಷ್ಟವಾಗಿವೆ. ಸೈಟ್ A ನಲ್ಲಿ:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

ಸೈಟ್ B ಯ conn ಎರಡು ಸಬ್ನೆಟ್ಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಅವು ಒಪ್ಪದಿದ್ದಾಗ, ಪ್ರತ್ಯುತ್ತರದಾತ ಚೈಲ್ಡ್ SA ಅನ್ನು TS_UNACCEPTABLE ನೊಂದಿಗೆ ನಿರಾಕರಿಸುತ್ತದೆ, ಹೀಗಾಗಿ IKE_SA ಏರಿದರೂ ಚೈಲ್ಡ್ SA ಎಂದಿಗೂ ಏರುವುದಿಲ್ಲ. ಎರಡೂ ಕಡೆ ಸಂರಚಿಸಿದ ಸಬ್ನೆಟ್ ಸ್ಥಳೀಯ ಕರ್ನಲ್ ಟನೆಲ್ನತ್ತ ರೂಟ್ ಮಾಡುವುದಕ್ಕೆ ಸಮನಾಗಿರಬೇಕು.

WireGuard ಅದೇ ಮಾಹಿತಿಯನ್ನು AllowedIPs ನಲ್ಲಿ ಸಾಗಿಸುತ್ತದೆ, ಒಂದು ವಿಶೇಷತೆಯೊಂದಿಗೆ: AllowedIPs ಸ್ವೀಕರಿಸುವಾಗ ಮೂಲ ಫಿಲ್ಟರ್ ಮತ್ತು ಕಳುಹಿಸುವಾಗ ಮಾರ್ಗ. ಸೈಟ್ B ಯ ಸೈಟ್ A ಗಾಗಿನ peer ನಮೂದು 2001:db8:a1:10::/64 ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ, ಸೈಟ್ A ಯಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್ಗಳು ಮಾನ್ಯ handshake ಮೇಲೆ ಬಂದು ಅನುಮತಿಸದಿರುವಂತೆ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆ. ಇದು ಪರಿಚಿತ ಮಾದರಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: handshake ಮಾತ್ರ ಮತ್ತೆ ಮತ್ತೆ ನವೀಕರಿಸುತ್ತದೆ, ಉತ್ತರ ಎಂದಿಗೂ ಹೊರಡುವುದಿಲ್ಲ. ಎರಡೂ ತುದಿಗಳನ್ನು wg show wg0 allowed-ips ನೊಂದಿಗೆ ಹೋಲಿಸಿ. ನಿಯೋಗ ಬದಲಾದಾಗಲೆಲ್ಲಾ ಆ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ; ಹಳೆಯ /64 ಸೆಷನ್ ಅನ್ನು ಜೀವಂತವಾಗಿ ಇಟ್ಟು ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ತಲುಪಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ.

ಮೊದಲು ಫಾರ್ವರ್ಡಿಂಗ್, firewall ಮತ್ತು MTU ಅನ್ನು ಹೊರಗಿಡಿ

ಇನ್ನೊಂದು ಲಾಗ್ ಸಾಲನ್ನು ಓದುವ ಮೊದಲು ಗೇಟ್ವೇಗಳು ಒಟ್ಟಾರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. sysctl net.ipv6.conf.all.forwarding ಎರಡರಲ್ಲೂ 1 ಅನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು, ಟನೆಲ್ ಮತ್ತು LAN ಇಂಟರ್ಫೇಸ್ಗಳಿಗೂ ಅನ್ವಯಿಸಬೇಕು. ಒಂದು ಬಲೆ ಜೊತೆಗಿದೆ: ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಆದ ನಂತರ accept_ra=1 ಇರುವ ಇಂಟರ್ಫೇಸ್ ಪೂರೈಕೆದಾರರ ರೂಟರ್ ಜಾಹೀರಾತುಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಹೀಗಾಗಿ ಟನೆಲ್ ಒಳಗೆ ಪರಿಪೂರ್ಣವಾಗಿ ರೂಟ್ ಮಾಡುತ್ತಿದ್ದರೂ ಸಾಧನವು ತನ್ನ ಅಪ್ಸ್ಟ್ರೀಮ್ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಪೂರೈಕೆದಾರರ RA ಇನ್ನೂ ಬೇಕಾದಲ್ಲಿ accept_ra=2 ಹೊಂದಿಸಿ.

ನಂತರ firewall ನಿಯಮಗಳು ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ICMPv6 ಉಳಿಯಬೇಕು: ನೆರೆಹೊರೆ ಪತ್ತೆ, packet-too-big ಮತ್ತು destination-unreachable ಐಚ್ಛಿಕವಲ್ಲ. ಅವನ್ನು ಬಿಟ್ಟರೆ ಪಥ MTU ಪತ್ತೆ ಮುರಿಯುತ್ತದೆ, ಸಂಪರ್ಕಗಳು ತೆರೆದು ನಂತರ ಮೊದಲ ದೊಡ್ಡ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ನಿಂತುಕೊಳ್ಳುತ್ತವೆ. ಕನಿಷ್ಠ ನಿಯಮಗಳ ಜೋಡಿ ಹೀಗಿದೆ:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU ಅದರ ಹಿಂದೆ ಇದೆ. ಟನೆಲ್ ಬಳಸಬಹುದಾದ MTU ಅನ್ನು 1500 ಕ್ಕಿಂತ ಕೆಳಗೆ ಕುಗ್ಗಿಸುತ್ತದೆ, ಮತ್ತು IPv6 ಪ್ರತಿ ಲಿಂಕ್ ಕನಿಷ್ಠ 1280 ಅನ್ನು ಸಾಗಿಸಬೇಕೆಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಸಣ್ಣ ಪಿಂಗ್ಗಳು ಹಾದುಹೋಗುತ್ತವೆ, SSH ಸೆಷನ್ ದೊಡ್ಡ ಸ್ಫೋಟದಲ್ಲಿ ಸ್ತಬ್ಧವಾಗುತ್ತದೆ, ಮತ್ತು /proc/net/snmp6 ಎಂದಿಗೂ ಹಿಂತಿರುಗದ packet-too-big ಸಂದೇಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಟನೆಲ್ MTU ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಿ, ಅಥವಾ mangle ಕೋಷ್ಟಕದಲ್ಲಿ TCP MSS ಅನ್ನು ಕ್ಲ್ಯಾಂಪ್ ಮಾಡಿ, ಮತ್ತು ಚಿಕ್ಕ MTU ಅನ್ನು ತಿಳಿಸುವ ICMPv6 ಹಿಂತಿರುಗಲು ಬಿಡಿ.

ಟನೆಲ್ ವಿಳಾಸವಲ್ಲ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಅತಿ ಹೆಚ್ಚು ಸಮಯ ತಿನ್ನುವ ವೈಫಲ್ಯ ಏಕಮುಖ ರೂಟಿಂಗ್. ಪ್ರತಿ ಗೇಟ್ವೇ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಟನೆಲ್ಗೆ ರೂಟ್ ಮಾಡುತ್ತದೆ, ಆದರೆ ಹೋಸ್ಟ್ಗಳು ತಮ್ಮದೇ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಮೂಲಕ ಉತ್ತರಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಅವುಗಳ /64 ಅಲ್ಲಿಯೇ ಇದೆ. ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ತಲುಪಿಸುವುದು ಅರ್ಧ ಮಾರ್ಗ ಮಾತ್ರ.

ಎರಡು ಆಜ್ಞೆಗಳು ಬಹುಪಾಲನ್ನು ಬಗೆಹರಿಸುತ್ತವೆ. ಸೈಟ್ A ನಲ್ಲಿ ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ಆ ಮೂಲದಿಂದ ಬರುವ ಪ್ರತಿಕ್ರಿಯೆ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ; ಸೈಟ್ B ನಲ್ಲಿ ಕನ್ನಡಿ ಪರಿಶೀಲನೆ ನಡೆಸಿ. ನಂತರ ಗೇಟ್ವೇ ಬದಲು ಹೋಸ್ಟ್ನಿಂದ ಟ್ರಾಫಿಕ್ ಉತ್ಪಾದಿಸಿ ಮತ್ತು ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಕೌಂಟರ್ಗಳನ್ನು ಹೋಲಿಸಿ.

ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ಗಾಗಿ ನೆರೆಹೊರೆಯ ಕೋರಿಕೆ ಟನೆಲ್ನಲ್ಲಿ ಕಾಣಿಸಿದರೆ, ಆ ಪ್ರಿಫಿಕ್ಸ್ ಇರಬಾರದ ಸ್ಥಳದಲ್ಲಿ on-link ಆಗಿದೆ; ಮಾರ್ಗಗಳನ್ನು ಸರಿಹೊಂದಿಸುವ ಮೊದಲು ಅದನ್ನು ಸರಿಪಡಿಸಿ. Proxy NDP ಬ್ರಿಡ್ಜಿಂಗ್ ನಿಜವಾಗಿ ಬೇಕಾದ ಸಂದರ್ಭಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಮಾರ್ಗಕ್ಕೆ ಬದಲಿಯಲ್ಲ.

ನಿಮ್ಮ ಅಡಿಯಲ್ಲಿ ಪ್ರಿಫಿಕ್ಸ್ ಬದಲಾಗುವುದನ್ನು ಯೋಜಿಸಿ

ಪ್ರಿಫಿಕ್ಸ್ ನಿಯೋಗವು ನಿಯೋಗಿಸುವ ಮತ್ತು ಕೇಳುವ ರೂಟರ್ಗಳ ನಡುವಿನ ಗುತ್ತಿಗೆ, ಮತ್ತು ನವೀಕರಣವು ಬೇರೆ ಬ್ಲಾಕ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು: ಪೂರೈಕೆದಾರರ ಸ್ಥಳಾಂತರದ ನಂತರ ಬೇರೆ /56, ಅಥವಾ ಟನೆಲ್ ಇದ್ದ ಅವಧಿಗಿಂತ ಚಿಕ್ಕ ಗುತ್ತಿಗೆ. ಹಳೆಯ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಹೆಸರಿಸುವ ಪ್ರತಿ ಸ್ಥಳವೂ ಒಂದೇ ಬಾರಿಗೆ ಹಳೆಯದಾಗುತ್ತದೆ: ಮಾರ್ಗಗಳು, ಸೆಲೆಕ್ಟರ್ಗಳು, AllowedIPs, firewall ನಿಯಮಗಳು, DNS ದಾಖಲೆಗಳು ಮತ್ತು ಅಕ್ಷರಶಃ ವಿಳಾಸಗಳನ್ನು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಿರುವ ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣೆ. ಸಂದೇಶ ಹರಿವು RFC 8415 ನಲ್ಲಿದೆ.

ಪ್ರಿಫಿಕ್ಸ್ ಚಲಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿದಲ್ಲಿ, ಅದನ್ನು ಅವಲಂಬಿಸದ ಆಂತರಿಕ ವಿಳಾಸ ಯೋಜನೆಯನ್ನು ಇಟ್ಟುಕೊಂಡು ಗಡಿಯಲ್ಲಿ ಅನುವಾದಿಸಿ. NPTv6 ಸ್ಥಿತಿರಹಿತ ಆಯ್ಕೆಯಾಗಿದ್ದು ಆಂತರಿಕ ನೀತಿಯನ್ನು ಓದಬಹುದಾದಂತೆ ಇಡುತ್ತದೆ, ಆದರೆ ಇದು ಪ್ರಿಫಿಕ್ಸ್ ಅನುವಾದ, ಮಾಂತ್ರಿಕ ಪದರವಲ್ಲ: /64 ಗಡಿಗಳು ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಚೆಕ್ಸಮ್ಗಳು ಸರಿಹೊಂದಿಸಲ್ಪಡುತ್ತವೆ, ಮತ್ತು ಅಕ್ಷರಶಃ ವಿಳಾಸಗಳನ್ನು ಎಂಬೆಡ್ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಇನ್ನೂ ಮುರಿಯುತ್ತವೆ. ಪೂರೈಕೆದಾರರ ವಿಳಾಸಗಳನ್ನು ತುದಿಯಿಂದ ತುದಿಗೆ ಇಟ್ಟುಕೊಂಡರೆ, ಗುತ್ತಿಗೆ ವರ್ತನೆ ಮತ್ತು ಬದಲಾವಣೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ವಿಳಾಸ ಯೋಜನೆಯಲ್ಲಿ ದಾಖಲಿಸಿ.

ಕಾಲವನ್ನು ತಾಳುವ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಮುಗಿಸಿ: ಪ್ರತಿ LAN ನಲ್ಲಿನ ಅನುಮತಿಸಿದ ಹೋಸ್ಟ್ ಇನ್ನೊಂದು LAN ನಲ್ಲಿನ ಸೇವೆಯನ್ನು ತಲುಪುತ್ತದೆ, ಪ್ರತಿಕ್ರಿಯೆ ಟನೆಲ್ ಮೂಲಕ ಹಿಂತಿರುಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಜೋಡಿ ಟನೆಲ್ ಮರುಪ್ರಾರಂಭ ಮತ್ತು ನಿಯೋಗ ನವೀಕರಣದ ನಂತರವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಕೊನೆಯ ಭಾಗ ವಿಫಲವಾದರೆ, ವಿನ್ಯಾಸವು ವಾರವನ್ನು ದಾಟದ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ.