Pse një portë e firewall-it e lidhur me gjendjen e VPN-së nuk është rregull ping vetëm përmes tunelit

Imagjinoni një rregull firewall-i që ndez ICMP echo për adresën publike të serverit sa herë që një profil VPN i emërtuar është i lidhur. Lexohet si «ping vetëm përmes tunelit», dhe ky lexim është i gabuar në një mënyrë që ka rëndësi. Rregulli nuk kufizon kush mund të arrijë hostin; ndryshon atë që përgjigjet ndërfaqja publike ndërsa një lidhje tjetër është aktive rastësisht. Këto janë dy politika të ndryshme, dhe njëra prej tyre zgjeron ekspozimin në heshtje.

Rregulli që mendoni se keni shkruar

Kërkesa e synuar zakonisht është e ngushtë: sistemi i monitorimit, ose administratori i vetëm në VPN, duhet të mund të konfirmojë se serveri është i gjallë. E shkruar si fjali, tingëllon si kontroll aksesi mbi tunelin. E shkruar si objekt firewall-i, bëhet kusht mbi profilin publik, sepse aty mbërrin kërkesa echo.

Pasi kushti bëhet gjendje lidhjeje dhe jo adresë burimore, bashkësia e dërguesve të lejuar nuk është më bashkësia e partnerëve të VPN-së. Kushdo që arrin adresën publike mund të dërgojë një kërkesë echo sa kohë porta është e hapur. Tuneli nuk u bë rruga; tuneli u bë çelësi.

Njerëzit që promovojnë këtë ide zakonisht nuk gënjejnë për efektin që donin. U duhej një kontroll që përgjigjet vetëm kur lidhja është e shëndoshë, dhe shëndeti i lidhjes matej më lehtë përmes VPN-së. Gabimi është të trajtosh një sinjal disponueshmërie si vendim aksesi, dhe pastaj ta automatizosh.

Çfarë kontrollon vërtet porta

Ky dizajn shkrin dy gjëra të pavarura, dhe ndarja e tyre është pjesa më e madhe e korrigjimit. E para është shtrirja: cila adresë lokale, cilat adresa të largëta, cili protokoll dhe cili tip ICMP. E dyta është kushti: nëse objekti i rregullit është i aktivizuar në këtë moment. Shtrirja është ajo që vlerëson një firewall për çdo paketë; kushti është ajo që një skript shkruan në depon e politikave, dhe të dyja pajtohen në orë krejt të ndryshme.

Nëse kërkesa është vërtet vetëm partnerët e VPN-së, shtrirja përgjigjet pa asnjë logjikë të gjendjes së lidhjes: lidhni rregullin me ndërfaqen e tunelit ose me intervalin e adresave të tunelit, kufizoni adresat e largëta në grupin e klientëve dhe specifikoni tipin echo në vend të «ICMP». Ai rregull mbetet i saktë kur nuk është aktiv asnjë VPN dhe nuk mund të hapet nga një profil i palidhur.

Nëse kërkesa është vërtet një portë publike, thojeni në tekstin e politikës, sepse kriteret e pranimit ndryshojnë. Një portë publike duhet të emërojë profilin e saktë, të përcaktojë çfarë do të thotë «i lidhur» dhe të deklarojë se dërguesit publikë janë në shtrirje sipas dizajnit. Pjesa më e madhe e konfuzionit zhduket në momentin kur dikush detyrohet ta shkruajë atë fjali.

Ndërtojeni objektin një herë, pastaj ndërrojeni

Parashikoni një rregull të vetëm me identitet të qëndrueshëm, të çaktivizuar, dhe lërini kontrolluesin të ndryshojë vetëm gjendjen e aktivizimit. Krijimi i rregullave sipas emrit të shfaqur në çdo ekzekutim është mënyra se si një depo politikash përfundon me pesë objekte pothuajse identike dhe pa mënyrë të besueshme për t'i hequr.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Emri është identifikuesi i qëndrueshëm; emri i shfaqur është dokumentacion që një njeri mund ta modifikojë. Pajtohuni sipas -Name dhe skripti ndalon prodhimin e dublikatave. E njëjta formë komande mbulon rastin IPv6 me -Protocol ICMPv6 -IcmpType 128, por ai është rregull i veçantë sepse numrat e tipit echo ndryshojnë midis dy familjeve.

Mbani familjen e adresave dhe tipin ICMP eksplicite edhe për një arsye të dytë: -Protocol ICMPv4 pa tip lejon çdo mesazh ICMPv4 që profili lejon, duke përfshirë ata që nuk keni pasur kurrë ndërmend t'i pranoni. Emërtimi i tipit 8 e ngushton rregullin në kërkesën echo, dhe vetëm këtë dërgon një kontroll arritshmërie.

Ku automatizimi kundërshton qëllimin

Anketimi i një profili klienti çdo pak minuta nuk mund të prodhojë një kufi të menjëhershëm. Midis rënies së lidhjes dhe anketimit të radhës rregulli ende përgjigjet në adresën publike; midis ngritjes së lidhjes dhe anketimit të radhës nuk përgjigjet. Ta pranosh atë vonesë është e ndershme, të pohtosh se dizajni imponon një invariante të rreptë nuk është.

Ka një grackë shtrirjeje në vetë kontrollin e gjendjes. Get-VpnConnection raporton profilet e klientit të konfiguruara në makinë, si parazgjedhje për përdoruesin aktual dhe për të gjithë përdoruesit me -AllUserConnection. Nuk raporton përdoruesit e largët që janë aktualisht të lidhur me një server RRAS; ai është një vëzhgim tjetër me një komandë tjetër. Një portë e ndërtuar mbi të gabuarën nuk është e lidhur me asgjë.

Pastaj mbuloni gjendjet që askush nuk i skripton: nisja me rregullin tashmë të aktivizuar nga një ekzekutim i mëparshëm, rrëzimi i kontrolluesit ndërsa porta është e hapur dhe një profil i fshirë ndërsa rregulli i tij mbetet i gjallë. Secili kërkon një parazgjedhje të përcaktuar, dhe parazgjedhja e sigurt për një leje publike është e çaktivizuar. Nëse kërkesa vërtet nuk e duron dritaren e anketimit, një rregull i lidhur me gjendjen është mjeti i gabuar dhe zbatimi i takon tunelit, jo ndërfaqes publike.

Së fundi, provoni kërkesën publike dy herë, një herë me lidhjen e zgjedhur aktive dhe një herë me të ulur, nga një host që nuk është në VPN. Një ping i suksesshëm nga brenda tunelit nuk provon asgjë për këtë politikë, dhe pikërisht atë matje shumica e vendosjeve e anashkalojnë.