ಎಲ್ಲಾ ಪೋರ್ಟ್‌ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿಯಮ ನಿಮ್ಮ WireGuard ಕೇಳುಗನನ್ನು ನುಂಗಬಹುದು
ಅಗಲವಾದ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿಯಮ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ WireGuard ಮತ್ತು SSH ಕೇಳುಗರನ್ನು ನುಂಗಬಹುದು. ಕಿರಿದಾದ ನಿಯಮಗಳನ್ನು ಅಥವಾ ಪ್ರತ್ಯೇಕ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಆರಿಸಿ, ನಂತರ ನಿಯಂತ್ರಣ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಸಾರ್ವಜನಿಕ ಗೇಟ್‌ವೇ ಈಗಾಗಲೇ UDP 51820 ನಲ್ಲಿ WireGuard, 22 ನಲ್ಲಿ SSH ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ತಲುಪಬೇಕಾದ ಒಂದು ಅನ್ವಯವನ್ನು ನಡೆಸುತ್ತಿದೆ. ಆಮಿಷದ ನಿಯಮವು ಪ್ರತಿ ಪೋರ್ಟ್ ಅನ್ನು ಪೀರ್‌ನತ್ತ ಕಳುಹಿಸಿ ಕೆಲಸ ಮುಗಿಯಿತು ಎನ್ನುತ್ತದೆ. WireGuard ಗೇಟ್‌ವೇಯಲ್ಲಿ ಅಂತಹ ನಿಯಮವು ಸುರಂಗದ ಸ್ವಂತ ಸಾಗಣೆಯನ್ನು ಹಿಡಿದು ಅದನ್ನು ಕೊನೆಗೊಳಿಸುವ ಯಂತ್ರದಿಂದ ನಿಮ್ಮನ್ನು ಲಾಕ್ ಔಟ್ ಮಾಡಬಹುದು. ಪ್ರಕಟಣೆ ಎಂಬುದು ನಿಯಂತ್ರಣ ಸಮತಲದ ವಿನಾಯಿತಿಯೊಂದಿಗಿನ ಮಾರ್ಗನಿರ್ಣಯದ ನಿರ್ಧಾರ, ಒಂದೇ DNAT ಸಾಲಲ್ಲ.
ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶ ಅಥವಾ ಸುರಂಗ ಪ್ರವೇಶ: ಒಂದನ್ನು ಆರಿಸಿ
ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸುವುದು ಇಂಟರ್ನೆಟ್‌ಗೆ ಹೊಸ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಇದು ಪೀರ್‌ಗೆ VPN ಸದಸ್ಯತ್ವ ನೀಡುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ, ಏಕೆಂದರೆ ಸಂದರ್ಶಕರು ಎಂದಿಗೂ ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುವುದಿಲ್ಲ ಮತ್ತು ಗೇಟ್‌ವೇ ಬ್ಯಾಕೆಂಡ್‌ನ ಸಾರ್ವಜನಿಕ ಮುಖವಾಗುತ್ತದೆ. ಆ ವ್ಯತ್ಯಾಸವೇ ನಿಯಮದ ಪ್ರೇಕ್ಷಕರನ್ನು ಮತ್ತು ಅದರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಆಡಳಿತಾತ್ಮಕ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಆ ಸ್ಥಾನಕ್ಕೆ ಅಪರೂಪವಾಗಿ ಸೇರುತ್ತವೆ. ಅಧಿಕೃತ VPN ಗ್ರಾಹಕರು ತಲುಪುವ ನಿರ್ವಾಹಕ ಪುಟವು ದಾಳಿಯ ಮೇಲ್ಮೈಯನ್ನು ಸುರಂಗದೊಳಗೆ ಇಡುತ್ತದೆ ಮತ್ತು ಯಾದೃಚ್ಛಿಕ ಸ್ಕ್ಯಾನಿಂಗ್‌ಗೆ ಲಾಗಿನ್ ನಮೂನೆಯನ್ನು ಒಡ್ಡುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ಅನ್ವಯ ತುದಿ ಬಿಂದುಗಳಿಗೆ ಇನ್ನೂ ತಮ್ಮದೇ TLS ಪ್ರಮಾಣಪತ್ರ, ದೃಢೀಕರಣ ಮತ್ತು ದರ ಮಿತಿ ಬೇಕು; ಗೂಢಲಿಪೀಕೃತ WireGuard ಹೆಜ್ಜೆ ಸಂದರ್ಶಕರ ಭಾಗವನ್ನು ಗೇಟ್‌ವೇವರೆಗೆ ರಕ್ಷಿಸುವುದಿಲ್ಲ.
ಸೇವೆ ನಿಜವಾಗಿಯೂ ಸಾರ್ವಜನಿಕವಾಗಿರಬೇಕಾದರೆ, ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು, ಅದನ್ನು ಆವರಿಸುವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮತ್ತು ಅದನ್ನು ತಲುಪಬೇಕಾದ ಸಂದರ್ಶಕ ಶ್ರೇಣಿಗಳನ್ನು ಬರೆಯಿರಿ. ಆ ಮೂರು ಸತ್ಯಗಳು ನಂತರ ನಿಯಮದ ಆಕಾರ ಮತ್ತು ಶೋಧಕ ನೀತಿಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಅವುಗಳ ಹೊರಗಿನದು ಸಾರ್ವಜನಿಕ ಕೇಳುಗನ ಮೇಲಿನ ವ್ಯಾಪ್ತಿ ವಿಸ್ತರಣೆ.
ಒಂದು ಪೋರ್ಟ್ ಒಳಗೆ, ಒಂದು ಬ್ಯಾಕೆಂಡ್ ಹೊರಗೆ
ಒಂದು ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ಮತ್ತು ಒಂದು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಯನ್ನು ಬಳಸಿ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ eth0 ಸಾರ್ವಜನಿಕ ವಿಳಾಸ 198.51.100.20 ಅನ್ನು ಹೊತ್ತಿದೆ, ಗೇಟ್‌ವೇಯ ಸುರಂಗ ವಿಳಾಸ 10.200.0.1, ಮತ್ತು ಪೀರ್ ಅನ್ವಯವನ್ನು 10.200.0.7 ನಲ್ಲಿ ನಡೆಸುತ್ತದೆ. ಸಾರ್ವಜನಿಕ TCP 9443 ಪೀರ್‌ನ TCP 8443 ಗೆ ನಕ್ಷೆ ಮಾಡಲಾಗುತ್ತದೆ:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT ನಿಯಮವು ಅನುವಾದಿತ ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ಮೂಲ ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದೇ ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗೆ ಇನ್ನೊಂದು ಸಂಪರ್ಕ ಈ ನಕ್ಷೆಯ ಹೊರಗೆ ಉಳಿಯುತ್ತದೆ. ಇದು ಸಂದರ್ಶಕರ ವಿಳಾಸವನ್ನು ಪೀರ್‌ನಿಂದ ಮರೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಮೂಲವನ್ನು ಸಂರಕ್ಷಿಸುವ ಮಾರ್ಗಿತ ಹಿಂತಿರುಗುವಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕ ವಿನ್ಯಾಸವನ್ನಾಗಿ ಮಾಡುವ ವಿನಿಮಯ ಅದೇ. iptables ವಿಸ್ತರಣೆಗಳ ಉಲ್ಲೇಖ ಎರಡೂ ಗುರಿಗಳನ್ನು ಮತ್ತು ಅವುಗಳ ಹೊಂದಾಣಿಕೆ ಆಯ್ಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಇನ್ನೂ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು, ಮತ್ತು ಶೋಧಕ ಸರಪಳಿಗೆ ಅನುವಾದಿತ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಹಾಗೂ ಸ್ಥಾಪಿತ ಪ್ರತ್ಯುತ್ತರಗಳಿಗೆ ಅನುಮತಿ ಬೇಕು. FORWARD ಸರಪಳಿ DNAT ನಂತರ ಅನುವಾದಿತ ಗಮ್ಯಸ್ಥಾನವನ್ನು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ವಿರುದ್ಧ ಬರೆದ ನಿಯಮ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗೆ ಹೊಂದುವುದಿಲ್ಲ. ಅನುಮತಿಯನ್ನು ಬ್ಯಾಕೆಂಡ್ ಟುಪಲ್‌ನ ವಿರುದ್ಧ ಬರೆಯಿರಿ, ಸಾರ್ವಜನಿಕದ ವಿರುದ್ಧವಲ್ಲ.
ಪೀರ್ ಸೇವಾ ಸಂಪರ್ಕವನ್ನು ಗೇಟ್‌ವೇಯ ಸುರಂಗ ವಿಳಾಸದಿಂದ ಸ್ವೀಕರಿಸಿ ಪ್ರತ್ಯುತ್ತರವನ್ನು ಸುರಂಗದ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಬೇಕು. ಅದರ AllowedIPs ನಿಜವಾಗಿ ಸ್ವೀಕರಿಸುವ ಮೂಲಕ್ಕೆ ಅನುಮತಿ ನೀಡಬೇಕು, ಮತ್ತು ಮೂಲ ಅನುವಾದದಲ್ಲಿ ಅದು ಗೇಟ್‌ವೇಯ ಸುರಂಗ ವಿಳಾಸ, ಹಾಗೂ ಪ್ರತಿ ಪೀರ್‌ನಲ್ಲಿ ಅಗಲವಾದ 0.0.0.0/0 ನಮೂದು ಈ ವಿನ್ಯಾಸಕ್ಕೆ ಅಗತ್ಯವಿಲ್ಲ. ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಕೆಡವುವುದು ಆ ವಿಳಾಸವನ್ನು ತನ್ನ ಪಟ್ಟಿಯಲ್ಲಿ ಬಿಟ್ಟುಬಿಟ್ಟ ಪೀರ್, ಅಥವಾ ಸಂದರ್ಶಕರ ಸ್ವಂತ ವಿಳಾಸವನ್ನು ಬದಲಿಗೆ ಕಳುಹಿಸುವ ಮೂಲ-ಸಂರಕ್ಷಕ ವಿನ್ಯಾಸ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ನಿಯಮದಲ್ಲಿರುವುದಲ್ಲ, ಪೀರ್ ನಿಜವಾಗಿ ನೋಡುವ ಮೂಲವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಕೇಳುಗರನ್ನು ನಿಯಮದ ಹೊರಗೆ ಇರಿಸಿ
ಪ್ಯಾಕೆಟ್ ಸ್ಥಳೀಯ ಎಂದು ಯಂತ್ರ ನಿರ್ಧರಿಸುವ ಮೊದಲೇ ಗಮ್ಯಸ್ಥಾನ ಅನುವಾದ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ UDP 51820 ಎಲ್ಲಾ ಪೀರ್ ಸಂಪರ್ಕಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಪ್ರಕ್ರಿಯೆಗೆ ಅಲ್ಲ, ಪೀರ್‌ಗೆ ತಲುಪಬಹುದು. ನಿಯಮ ಯಶಸ್ವಿಯಾಗಿ ಲೋಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಸಾಯುತ್ತದೆ, ಇದು ಪೀರ್ ಕಡೆಯಿಂದ ಓದಲು ಕಷ್ಟವಾದ ವೈಫಲ್ಯ.
SSH, ಮೇಲ್ವಿಚಾರಣಾ ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು ಗೇಟ್‌ವೇಯಲ್ಲಿನ ಯಾವುದೇ ಇತರ ಸೇವೆಗೆ ಅದೇ ಒಡ್ಡುವಿಕೆ ಇದೆ. ಎಲ್ಲವನ್ನೂ ಕಳುಹಿಸುವ ನಿಯಮ ನಿಯಂತ್ರಣ ಸಮತಲವನ್ನು ಪ್ರಕಟಿತ ಅನ್ವಯದಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಬದಲಾವಣೆಯ ನಂತರದ ಮೊದಲ ಮರುಬೂಟ್ ಲಾಕ್ ಔಟ್ ಸ್ಪಷ್ಟವಾಗುವ ಕ್ಷಣ. ಎಲ್ಲವನ್ನೂ ಆವರಿಸುವ ನಿಯಮ ತಾನು ಮೌನವಾಗಿ ವಹಿಸಿಕೊಳ್ಳುವ ಸೇವೆಯ ಬಗ್ಗೆ ಎಚ್ಚರಿಸುವುದಿಲ್ಲ. ಮುಂದಿನ ಸಂಪರ್ಕ ವಿಫಲವಾದಾಗ ನೀವು ಅದನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ.
ಅಗಲವಾದ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾದರೆ, ಎಲ್ಲವನ್ನೂ ಆವರಿಸುವ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ನಿಯಂತ್ರಣ ಪೋರ್ಟ್‌ಗಳನ್ನು ಕಾಯ್ದಿರಿಸಿ ಅಥವಾ ಪ್ರಕಟಣೆಗೆ ಪ್ರತ್ಯೇಕ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಬಳಸಿ. ಎರಡನೆಯ ಆಯ್ಕೆ ಸ್ವಚ್ಛವಾದದ್ದು ಏಕೆಂದರೆ ನಿಯಂತ್ರಣ ವಿಳಾಸ ತನ್ನದೇ ನೀತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಪೂರೈಕೆದಾರರು ಆ ವಿಳಾಸವನ್ನು ನೀಡಬೇಕು; DNS ದಾಖಲೆ ಸೇರಿಸುವುದು ಒಂದನ್ನು ಹಂಚುವುದಿಲ್ಲ.
ಅಗಲವಾದ TCP ಮತ್ತು UDP ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಕೂಡ ಎಲ್ಲಾ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲ. ICMP, IPv6, ಮಾರ್ಗ MTU ಪ್ರತಿಕ್ರಿಯೆ ಮತ್ತು VPN ನ ಹೊರ ಸಾಗಣೆಗೆ ತಮ್ಮದೇ ನೀತಿ ಬೇಕು, ಮತ್ತು TCP ಹಾಗೂ UDP ಆವರಿಸುವ ನಿಯಮ ಆ ಪ್ರಕರಣಗಳನ್ನು ಪೂರ್ವನಿಯೋಜಿತ ಸರಪಳಿಗೆ ಬಿಡುತ್ತದೆ.
ನಿಯಮಗಳನ್ನು ಬರೆಯುವ ಮೊದಲು ಮಾದರಿಯನ್ನು ಆರಿಸಿ
ನಾಲ್ಕು ಆಕಾರಗಳು ಹೆಚ್ಚಿನ ಗೇಟ್‌ವೇ ಪ್ರಕಟಣೆಗಳನ್ನು ಆವರಿಸುತ್ತವೆ, ಮತ್ತು ಆಯ್ಕೆ ನೀವು ಎಷ್ಟು ಸೇವೆಗಳನ್ನು ನಡೆಸುತ್ತೀರಿ ಮತ್ತು ಎಷ್ಟು ನಿಯಂತ್ರಣ ಸಮತಲ ಅಪಾಯವನ್ನು ಸಹಿಸಬಹುದು ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಕೆಳಗಿನ ಕೋಷ್ಟಕ ಅವನ್ನು ಕಿರಿದಾದದ್ದರಿಂದ ಅಗಲವಾದದ್ದಕ್ಕೆ ಕ್ರಮಗೊಳಿಸುತ್ತದೆ.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
ನಂತರ ಹೆಚ್ಚು ಸೇವೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿದರೂ ಕಿರಿದಾದ ಮಾದರಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅತಿ ಸುಲಭ, ಮತ್ತು ಕಿರಿದಾದ ನಿಯಮಗಳ ಗುಂಪನ್ನು ಪರಿಶೀಲಿತ ಎಲ್ಲವನ್ನೂ ಆವರಿಸುವ ನಿಯಮವಾಗಿ ಪರಿವರ್ತಿಸುವುದು ಅಗಲವಾದ ನಿಯಮ ಯಾವ ಕೇಳುಗನನ್ನು ಹಿಡಿದಿತ್ತು ಎಂದು ಕಂಡುಹಿಡಿಯುವುದಕ್ಕಿಂತ ಸರಳ. ಯಾವ ಮಾದರಿ ಆರಿಸಿದರೂ ನಿಯಮಗಳನ್ನು ಫೈರ್‌ವಾಲ್ ಮಾಲೀಕರ ಬಳಿ ಇರಿಸಿ. ಅದೇ ಸರಪಳಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ UFW ಅಥವಾ nftables ಸಂರಚನೆಯ ಪಕ್ಕದಲ್ಲಿ iptables ಸಾಲುಗಳನ್ನು ಅನ್ವಯಿಸುವುದು ಬೂಟ್ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗುವ ನೀತಿಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಪ್ರಕಟಣೆ ಮತ್ತು ನಿಯಂತ್ರಣ ಮಾರ್ಗ ಎರಡನ್ನೂ ಸಾಬೀತುಪಡಿಸಿ
ಅನುಮೋದಿತ ಹೋಸ್ಟ್‌ಹೆಸ್ ಮತ್ತು ಅದಕ್ಕೆ ಮಾನ್ಯವಾದ ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ ಅಧಿಕೃತ ಹೊರಗಿನ ಗ್ರಾಹಕರಿಂದ ಪರೀಕ್ಷಿಸಿ. ಯಾವ ಬ್ಯಾಕೆಂಡ್ ಉತ್ತರಿಸಿತು ಎಂದು ದೃಢೀಕರಿಸಿ, ನಂತರ ಸಂಬಂಧವಿಲ್ಲದ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್‌ಗಳು ನಿರಾಕರಿಸಲ್ಪಟ್ಟಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಯಶಸ್ವಿ HTTPS ಪರೀಕ್ಷೆಯಲ್ಲ, ಮತ್ತು ತಪ್ಪು ಬ್ಯಾಕೆಂಡ್ ತಲುಪುವ ಸಂಪರ್ಕ ವಿಫಲವಾದದ್ದಕ್ಕಿಂತ ಕೆಟ್ಟದು.
ಅದರ ನಂತರ ಗೇಟ್‌ವೇಯನ್ನೇ ಪರಿಶೀಲಿಸಿ: WireGuard ಪೀರ್ ಸಂಪರ್ಕಿಸಿ, SSH ಅಧಿವೇಶನ ತೆರೆಯಿರಿ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಇನ್ನೂ ವರದಿ ಮಾಡುತ್ತಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ನಿಯಂತ್ರಣ ಸಮತಲ ಮುರಿದಿರುವಾಗ ಪ್ರಕಟಿತ ಸೇವೆ ಕೆಲಸ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಎರಡೂ ಪರಿಶೀಲನೆಗಳು ಒಂದೇ ಬದಲಾವಣೆ ಕಿಟಕಿಯಲ್ಲಿ ಇರಬೇಕು. ನಿಯಮಗಳು ನಿರೀಕ್ಷಿತ ಕ್ರಮದಲ್ಲಿ ಮತ್ತೆ ಅನ್ವಯವಾಗುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಒಮ್ಮೆ ಮರುಬೂಟ್ ಮಾಡಿ, ನಂತರ ಪ್ರಕಟಣೆಯನ್ನು ತೆಗೆದುಹಾಕಿ ತೆಗೆದುಹಾಕುವಿಕೆ ಸೇರಿಸುವಿಕೆಗೆ ನಿಜವಾಗಿ ಹೊಂದುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಆರಂಭದಲ್ಲಿ ಹಲವು ಸೇರ್ಪಡೆಗಳು ಮತ್ತು ಅಪೂರ್ಣ ತೆರವು, ಹೀಗೆ ತಾತ್ಕಾಲಿಕ ಪರೀಕ್ಷೆ ಶಾಶ್ವತ ತೆರವಾಗುತ್ತದೆ.