Çelësi i urgjencës bllokon vetëm IPv4: pse IPv6 prapë del
Një grup rregullash të firewall-it për IPv4 nuk thotë asgjë për IPv6. Në një pajisje me stivë të dyfishtë, tuneli mund të bjerë ndërsa një aplikacion mban një rrugë funksionale përreth tij.
Tuneli bie, çelësi i urgjencës raporton se ka vepruar, dhe një shkarkim vazhdon. Asgjë nuk është prishur në rregullat e IPv4. Aplikacioni thjesht u zhvendos në një rrugë për të cilën ato rregulla nuk u shkruan kurrë.
Pajisjet me stivë të dyfishtë kanë dy rrugëdalje të pavarura. Një bllokim në njërën prej tyre është gjysmë bllokimi.
Dy grupe rregullash, dy vlera të paracaktuara
Në Linux, iptables dhe ip6tables janë tabela të veçanta me politika të veçanta. Vendosja e zinxhirëve INPUT dhe OUTPUT të tabelës IPv4 në DROP nuk ndryshon asgjë në tabelën IPv6, ku vlera e paracaktuar është zakonisht ACCEPT. E njëjta ndarje ekziston në nftables, ku mund të inspektoni një familje dhe të zbuloni se vetëm njëra prej tyre mban rregullat tuaja. Kjo asimetri është normale, dhe është i gjithë problemi.
Kjo është arsyeja pse një çelës urgjence mund të duket i plotë dhe të sillet pjesërisht. Skripti që shkroi rregullat e IPv4 u ekzekutua, numëruesit rriten, rreshti i regjistrit shfaqet, dhe një paketë IPv6 del nga ndërfaqja fizike plotësisht e paprekur.
Lexoni çfarë instalon në të vërtetë klienti juaj, jo çfarë premton faqja e marketingut. Disa klientë e drejtojnë IPv6-n në tunel, të tjerë e bllokojnë qëllimisht, dhe të tjerë e lënë të qetë ndërsa një bllokim në nivel platforme zbaton një rregull tjetër. Dokumentacioni i furnizuesit është i vetmi burim që ia vlen të besohet këtu.
Çfarë ju thotë konfigurimi i ndërfaqes
Faqja e manualit të wg-quick përfshin rregulla IPv6 në konfigurimin e saj shembull, dhe arsyeja është pikërisht kjo boshllëk. Shembulli nuk është dekor. Ai ekziston sepse vetëm rregullat e IPv4 do ta linin familjen e dytë të hapur.
Kopjimi i gjysmës së një shembulli prodhon gjysmën e një politike. Kjo është origjina më e zakonshme e këtij rrjedhjeje. Një postim blogu e shkurtoi shembullin për arsye gjatësie. Versioni i shkurtuar më pas u bë modeli që të gjithë e ripërdorën.
# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20
# nftables: inspect each family separately
sudo nft list ruleset inet | head -40
# does this host even have a usable IPv6 path?
ip -6 route show default
Nëse komanda e dytë printon një politikë lejuese ndërsa e para printon DROP, ju e keni gjetur përgjigjen pa e prekur klientin. Kjo asimetri është defekti.
Pse një kërkim i vetëm nuk është e gjithë historia
Një emër i vetëm mund të kthejë një regjistrim A dhe një regjistrim AAAA, dhe aplikacionet nuk zgjedhin të gjitha në të njëjtën mënyrë. Një shfletues mund të preferojë IPv6 kur rrjeti e ofron dhe të tërhiqet kur dështon, ndërsa një sinkronizim në sfond ose një përditësues përdor zgjidhësin dhe preferencën e vet. Prandaj, një test i suksesshëm mbi IPv4 provon një rrugë, jo politikën.
Tranzicionet e rrjetit ndryshojnë gjithashtu përgjigjen. Lidhja me një rrjet tjetër Wi-Fi, zgjimi nga gjumi ose kalimi në rrjet celular mund t'i japë pajisjes një prefiks të ri IPv6, dhe politika që dukej e mjaftueshme në LAN-in e zyrës mund të mos e mbulojë atë.
Testoni gjendjen kur tuneli është i fikur
Testimi ndërsa jeni i lidhur ju thotë se tuneli funksionon. Testi interesant është gjendja e padisponueshme, sepse atëherë çelësi i urgjencës duhet të mbajë. Ndaloni tunelin me qëllim, pastaj provoni destinacionet e rëndësishme nga aplikacioni që po mbroni.
# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/
Të dyja familjet duhet të dështojnë të mbyllura. Nëse kërkesa IPv4 skadon dhe kërkesa IPv6 kthen një kod statusi, politika është e paplotë, dhe asnjë sasi ritestimi i tunelit nuk do ta ndryshojë atë.
Mbani edhe përjashtimet e dokumentuara në atë test. Zbulimi i rrjetit lokal, një rinovim DHCP ose rruga e nisjes drejt pikës fundore VPN mund të kenë nevojë të mbeten të arritshme, dhe ato përjashtime duhet të emërtohen në politikë në vend që të zbulohen gjatë një ndërprerjeje. Një test rrjedhjeje që dështon sepse tuneli nuk mund të kthehet nuk është gjetje sigurie, është gjetje lidhshmërie.