ಒಂದು ಗೇಟ್‌ವೇ ಪ್ರಯಾಣಿಕ ಬಳಕೆದಾರರಿಗೆ IPv4 ಮತ್ತು IPv6 ಎರಡೂ ವರ್ಚುವಲ್ ವಿಳಾಸವನ್ನು ನೀಡಬಹುದು, ಆದರೆ ಹೊರಗಿನ ಟನಲ್ ಇನ್ನೂ IPv4 ಮೇಲೆ ಸಾಗುತ್ತದೆ. ಇವು ಸ್ವತಂತ್ರ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಅವನ್ನು ಒಂದಾಗಿ ಪರಿಗಣಿಸುವುದೇ ಡ್ಯುಯಲ್-ಸ್ಟಾಕ್ ಯೋಜನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಡೆಯುವ ಸ್ಥಳ. ಕ್ಲೈಂಟ್‌ನ ಒಳಗಿನ ಕುಟುಂಬಗಳು, ಅದು ತಲುಪಬಹುದಾದ ಸಂರಕ್ಷಿತ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು, ಮತ್ತು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಸಾಗಿಸುವ ಸಾರಿಗೆ ಮೂರು ಪ್ರತ್ಯೇಕ ಆಯ್ಕೆಗಳು.

ಹೆಚ್ಚಿನ ಗೊಂದಲ ಡ್ಯುಯಲ್ ಸ್ಟಾಕ್ ಎಂಬ ಪದವನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಡ್ಯುಯಲ್ ಸ್ಟಾಕ್ ಆಗಿರುವ ವಿನ್ಯಾಸಕ್ಕೆ ಅನ್ವಯಿಸುವುದರಿಂದ ಬರುತ್ತದೆ. ಸೇವೆಯು ಒಳಗೆ ಡ್ಯುಯಲ್ ಸ್ಟಾಕ್ ಆಗಿದ್ದು, ತನ್ನ ಹೊರಗಿನ ವಿಳಾಸದಲ್ಲಿ ಸಿಂಗಲ್ ಸ್ಟಾಕ್ ಆಗಿದ್ದರೂ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು. ಅದು ಮಾಡಲಾಗದ್ದು ಆಕಸ್ಮಿಕವಾಗಿ ಕೆಲಸ ಮಾಡುವುದು.

ಒಳಗೆ ಎರಡು ಕುಟುಂಬಗಳು, ಹೊರಗೆ ಒಂದು ಮಾರ್ಗ

ಹೊರಗಿನ ಸಂಪರ್ಕವು UDP ಮೇಲಿನ IKE, ಮತ್ತು ಕ್ಲೈಂಟ್ ಎಲ್ಲಿದ್ದರೂ ಅಲ್ಲಿಂದ ಒಂದು ತಲುಪಬಹುದಾದ ವಿಳಾಸ ಕುಟುಂಬ ಬೇಕು. ಒಳಗಿನ IPv6 ವಿಳಾಸಕ್ಕೆ IPv6 ಸಾಮರ್ಥ್ಯದ ISP ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ ಒಳಗಿನ ಪೇಲೋಡ್. ಅನೇಕ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ನಿಯೋಜನೆಗಳು IPv6 ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಕೇವಲ-IPv4 ಅಪ್‌ಲಿಂಕ್ ಮೂಲಕ ಸಾಗಿಸುತ್ತವೆ.

ಹೊರಗಿನ ಮಾರ್ಗವು ನಿಜವಾಗಿ ಮಿತಿಗೊಳಿಸುವುದು ತಲುಪುವಿಕೆ ಮತ್ತು NAT ಟ್ರಾವರ್ಸಲ್. ಗೇಟ್‌ವೇ ಕೇವಲ IPv4 ವಿಳಾಸವನ್ನು ಪ್ರಕಟಿಸಿದರೆ, ಕೇವಲ-IPv6 ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ನೀವು ಎಷ್ಟೇ ಪೂಲ್‌ಗಳನ್ನು ಸಂರಚಿಸಿದರೂ ಸಂಪರ್ಕಿಸಲೇ ಸಾಧ್ಯವಿಲ್ಲ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಜನಸಂಖ್ಯೆಯ ಆಧಾರದಲ್ಲಿ ಹೊರಗಿನ ಕುಟುಂಬವನ್ನು ನಿರ್ಧರಿಸಿ, ಒಳಗಿನ ವಿಳಾಸ ಯೋಜನೆಯಿಂದ ಅಲ್ಲ.

ಪ್ರತಿ ಕುಟುಂಬದಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗೆ ವಿಳಾಸ ನೀಡಿ

ಎರಡೂ ಕುಟುಂಬಗಳಿಗೆ ವಿನಂತಿಸುವುದು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಒಂದೇ ಸಾಲಿನ ಹೇಳಿಕೆ, ಗೇಟ್‌ವೇಯಲ್ಲಿ ಹಂಚಲು ಏನಾದರೂ ಇದ್ದರೆ. ಹೆಸರಿಸಿದ ಪೂಲ್‌ಗಳು ಮೂಲಗಳನ್ನು ಸೇವಾ ಜಾಲಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತವೆ, ಮತ್ತು ಈ ಗುಣವೇ ಆರು ತಿಂಗಳ ನಂತರ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

ಈ vips ಮೌಲ್ಯವು ಪ್ರತಿ ಕುಟುಂಬದಿಂದ ಒಂದು ವಿಳಾಸವನ್ನು ಕೇಳುತ್ತದೆ, ಮತ್ತು ಪೂಲ್‌ಗಳ ಪಟ್ಟಿ ಆ ವಿಳಾಸಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.strongSwan ನ ವರ್ಚುವಲ್-IP ದಾಖಲೆ ಬಹು ವಿನಂತಿಗಳು ಮತ್ತು ಪೂಲ್ ಹಂಚಿಕೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ವಿಳಾಸವನ್ನು ಕೇಳುವ ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆದಾರರು ರದ್ದುಗೊಳಿಸಬಹುದಾದ ಒಂದು ಆದ್ಯತೆಯನ್ನು ಮಾತ್ರ ವ್ಯಕ್ತಪಡಿಸುತ್ತಾನೆ ಎಂಬ ಅಂಶವೂ ಸೇರಿದಂತೆ. ಕ್ಲೈಂಟ್ ಯಾವಾಗಲೂ ಅದೇ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತಾನೆ ಎಂದು ಊಹಿಸುವ ಪ್ರವೇಶ ನಿಯಮವನ್ನು ನಿರ್ಮಿಸಬೇಡಿ.

ಉದಾಹರಣೆಯನ್ನು ನಕಲಿಸುವ ಬದಲು ನಿಮ್ಮದೇ ವಿಶಿಷ್ಟ ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್ ರಚಿಸಿ. ಎರಡೂ ಸಂಸ್ಥೆಗಳು fd42::/16 ಅಳವಡಿಸಿಕೊಂಡರೆ, ಮೊದಲ ಬಾರಿ ಪರಸ್ಪರ ಸಂಪರ್ಕಗೊಂಡಾಗ ಘರ್ಷಣೆಯನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅದನ್ನು ನಿರ್ಣಯಿಸುವುದು ಆಹ್ಲಾದಕರವಲ್ಲ.

ಸೆಲೆಕ್ಟರ್‌ಗಳು ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮೂಲಗಳನ್ನು ಅಲ್ಲ

ಚೈಲ್ಡ್ SA ಯ ಸ್ಥಳೀಯ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಗೇಟ್‌ವೇಯ ಹಿಂದೆ ಯಾವ ಸಂರಕ್ಷಿತ ಜಾಲಗಳಿವೆ ಎಂದು ಹೇಳುತ್ತವೆ, ಮತ್ತು ದೂರದ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಕ್ಲೈಂಟ್ ಮೂಲವಾಗಿ ಏನನ್ನು ಬಳಸಬಹುದೆಂದು ವಿವರಿಸುತ್ತವೆ. ವರ್ಚುವಲ್ ಪೂಲ್ ವಿಳಾಸವು ಆ ನೀತಿಯ ಮೂಲ ಭಾಗಕ್ಕೆ ಸೇರಿದೆ; ಅದನ್ನು ಗಮ್ಯಸ್ಥಾನ ಪಟ್ಟಿಗೆ ಹಾಕುವುದು ಸಂರಚನೆಯ ಸಾಮಾನ್ಯ ತಪ್ಪು ಓದಿಕೆ.

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

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

DNS ಮತ್ತು ಉತ್ತರದ ಮಾರ್ಗವು ಅದು ಪೂರ್ಣಗೊಂಡಂತೆ ಕಾಣುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ

ರೆಸಾಲ್ವರ್‌ನ ಉತ್ತರಗಳು ರೆಸಾಲ್ವರ್ ತಲುಪಲು ಬಳಸುವ ಸಾರಿಗೆಯಿಂದ ಸ್ವತಂತ್ರ. ಒಂದು ಹೆಸರು A ದಾಖಲೆ, AAAA ದಾಖಲೆ ಅಥವಾ ಎರಡನ್ನೂ ಹಿಂತಿರುಗಿಸಬಹುದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಆದ ಆದ್ಯತೆ ನಿಯಮಗಳ ಪ್ರಕಾರ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಒಳಗಿನ ಸೇವೆಯು AAAA ದಾಖಲೆಯನ್ನು ಪ್ರಕಟಿಸಿದರೂ ಆ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಯಾವುದೂ ರೂಟ್ ಮಾಡದಿದ್ದರೆ, ಡ್ಯುಯಲ್-ಸ್ಟಾಕ್ ಜಾಲಗಳಲ್ಲಿನ ಕ್ಲೈಂಟ್‌ಗಳು ಮೊದಲು IPv6 ಮಾರ್ಗವನ್ನು ಪ್ರಯತ್ನಿಸಿ ಅದು ವಿಫಲವಾಗುವವರೆಗೆ ಅಲ್ಲೇ ಕುಳಿತುಕೊಳ್ಳುತ್ತವೆ. ಆಗ ಟನಲ್ ಸಂರಚನೆಯಲ್ಲಿ ಏನೂ ತಪ್ಪಾಗಿ ಕಾಣುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಪ್ರತಿ ಹೆಸರಿಗೆ ಯಾವ ಕುಟುಂಬಗಳು ಬಳಸಲರ್ಹವೆಂದು ನಿರ್ಧರಿಸಿ, ನಂತರ ಸಂಬಂಧಿತ ಪ್ರಿಫಿಕ್ಸ್ ಸೆಲೆಕ್ಟರ್‌ನಲ್ಲಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಇದು ಸೇವೆ-ವಾರು ನಿರ್ಧಾರ. ಎರಡೂ ರೀತಿಯ ದಾಖಲೆಗಳನ್ನು ಭೇದವಿಲ್ಲದೆ ಪ್ರಕಟಿಸುವುದೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದ ಕೇವಲ-IPv4 ಸೇವೆಯು ತನ್ನ ಅರ್ಧದಷ್ಟು ಬಳಕೆದಾರರಿಗೆ ಸಮಯ ಮೀರಲು ಪ್ರಾರಂಭಿಸುವ ದಾರಿ.

ಪೂರ್ಣ ಎಂದು ಕರೆಯುವ ಮೊದಲು ಎರಡೂ ಕುಟುಂಬಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಲೋಡ್ ಆಗುವ ಸಂರಚನೆ ಕೆಲಸ ಮಾಡುವ ಸಂರಚನೆ ಅಲ್ಲ. ಡೀಮನ್ ವರದಿ ಮಾಡುವ ಸ್ಥಿತಿಯನ್ನು ಓದಿ, ಪೂಲ್ ಹಂಚಿಕೆಗಳನ್ನು ದೃಢೀಕರಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಸ್ಥಾಪಿಸಿದ ಮಾರ್ಗಗಳನ್ನು ನೋಡಿ.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

ಮೊದಲ ಎರಡು ಆದೇಶಗಳು ಸ್ಥಾಪಿತ ಚೈಲ್ಡ್ SA ಗಳನ್ನು ಮತ್ತು ಯಾವ ಪೂಲ್‌ಗಳಲ್ಲಿ ಇನ್ನೂ ವಿಳಾಸಗಳು ಲಭ್ಯವಿವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ, ಹೀಗೆ ಮೊದಲ ಕ್ಲೈಂಟ್‌ಗೆ ಕೆಲಸ ಮಾಡಿ ಹತ್ತನೆಯವರಿಗೆ ವಿಫಲವಾಗುವ ಯೋಜನೆ ಗೋಚರವಾಗುತ್ತದೆ. ಕೊನೆಯ ಎರಡು ಕ್ಲೈಂಟ್ ಪೂಲ್‌ನಿಂದ ಜಾಗತಿಕ IPv6 ವಿಳಾಸವನ್ನು ಪಡೆದಿದೆಯೇ ಮತ್ತು ಸಂರಕ್ಷಿತ ಪ್ರಿಫಿಕ್ಸ್‌ನತ್ತ ಸಂಚಾರ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ. ನಿಯೋಜಿಸಲಾದ ವಿಳಾಸವನ್ನು ನೀವು ಸಂರಚಿಸಿದ ಪೂಲ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ, ನೀವು ನಿರೀಕ್ಷಿಸಿದ ವಿಳಾಸದೊಂದಿಗೆ ಅಲ್ಲ. ಪ್ರತಿಕ್ರಿಯೆದಾರರು ತನ್ನ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಬೇರೆ ಮೌಲ್ಯವನ್ನು ಆರಿಸಿದ್ದರೆ, ಮಾರ್ಗಗಳು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಇನ್ನೂ ಅವನ ಆಯ್ಕೆಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.

ನಂತರ ಪ್ರತಿ ಕುಟುಂಬಕ್ಕೆ ಒಂದು ಸಂರಕ್ಷಿತ ಹೋಸ್ಟ್ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಎರಡಕ್ಕೂ ಪರಿಹರಿಸುವ ಹೆಸರನ್ನು ಪರೀಕ್ಷಿಸಿ. ಒಂದೇ ಕುಟುಂಬದ ಪರೀಕ್ಷೆ ನೀವು ಅಭ್ಯಾಸ ಮಾಡದ ಯೋಜನೆಯ ಅರ್ಧದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಕಾಣೆಯಾದ ಮಾರ್ಗ ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಅರ್ಧದಲ್ಲಿ ಇರುತ್ತದೆ.

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