Cloudni požarni zid proti požarnemu zidu gostitelja za strežnik VPN

Dovolite vrata VPN v cloudni politiki in rokovanje lahko vseeno umre na instanci: gost izvaja svoj filter in svojo vezavo poslušalca, in katero koli od tega lahko zavrže, kar je cloud odobril. Zgodi se tudi obratno, ko pravilo gostitelja dovoli vrata, politika nad njim pa jih zavrže prva. Dva lastnika, dva nabora pravil, ena pot paketa. Prehodite jo po vrsti, namesto da ugibate na najbolj sumljivi plasti.

Začnite na robu in pojdite navznoter

Vrstni red je fiksen: javna končna točka, vmesnik vira, pripeta cloudna politika, naslov gosta, poslušalec procesa, lokalna vhodna pravila. Vsaka stopnja bodisi spusti paket naprej bodisi konča preiskavo, zato začetek pri gostu izgubi največ časa.

Preusmerjeni promet odjemalcev je ločena stopnja, ki se pregleda po dekapsulaciji tunela. Cloudna plast vidi samo zunanji tunel, zato lahko odobri povezavo in vseeno nima nič opraviti z zahtevo notranje storitve. Tunel, ki se poveže, a ne doseže notranjega gostitelja, običajno kaže na preusmerjanje, ne na zaprta vrata.

Preberite cloudno politiko, preden se dotaknete gosta

Potrdite vhodno pravilo za vrata VPN, njegov protokol in obseg vira, ki ustreza vašemu preskusnemu odjemalcu. Preverite tudi seznam za nadzor dostopa podomrežja: drugi filter z lastnimi pravili in privzetimi vrednostmi. Oba morata dovoliti tok, preden paket doseže instanco. Dovoljenje v enem in zavrnitev v drugem je običajna oblika te napake.

Zožite obseg, dokler nekaj ne pomeni. Odpreti vrata VPN celemu internetu je lahko dokazati in težko braniti, medtem ko se pravilo, pripeto na en naslov, zlomi, ko preskusni odjemalec zamenja omrežje. Zapišite identifikator pravila in lastnika politike, da bo naslednja sprememba sledljiva do osebe.

Potrdite poslušalca, nato vhodno verigo

Na instanci preverite, ali je proces VPN vezan na naslov in vrata, ki jih pričakujete, na primer z ss -lntp 'sport = :1194'. Demon, vezan samo na 127.0.0.1, sprejema lokalne odjemalce in ničesar skozi tunel, kar od zunaj izgleda natanko kot filtrirana vrata.

Nato preberite lokalna pravila v sintaksi, ki bi jo uporabili za njihovo spremembo, na primer iptables -S INPUT ali nft list chain inet filter input. Pravilo, zapisano v datoteko, a nikoli naloženo, ali privzeto zavrženje brez ustreznega dovoljenja, tiho zavrže pakete. Za prehod, ki preusmerja, preverite tudi nastavitve preusmerjanja in povratne poti. Te odločajo, kaj se zgodi s paketi, usmerjenimi skozi instanco in ne naslovljenimi nanjo.

S stanjem v eni plasti, brez stanja v naslednji

Varnostne skupine si zapomnijo tokove, ki so jih dovolile, in spustijo odgovore nazaj. Seznami za nadzor dostopa podomrežij in mnogi požarni zidovi gostitelja takega stanja ne hranijo, zato pravilo, ki pokriva samo odhodno smer, spusti zahtevo in zavrže odgovor. Nikoli ne prenašajte predpostavke o povratnem prometu med plastmi, ne da bi prebrali pravilo druge plasti (second layer's rule).

Števci to razrešijo hitreje kot branje vsakega pravila v računu. Števec, ki narašča, pomeni, da je paket prispel in bil tam zavržen, tisti, zamrznjen na ničli, pa da tja nikoli ni prišel; iptables -vnL INPUT in nft list ruleset prikazujeta te številke, ko so bila pravila naložena s števci.

Preskusite s svežo sejo, ne z živo

Pustite izvorno omrežje in preskusni profil pri miru, medtem ko primerjate poglede, in po vsaki spremembi odprite novo povezavo. Doseči spletno konzolo na 443 ne pove nič o tem, ali je demon VPN vezan na 1194, zato preskusite vrata, ki jih potrebujete. Obstajajoča seja je tu najslabša priča. Deluje naprej, medtem ko je vsaka nova prijava zavrnjena.

Pred urejanjem oddaljene politike si zagotovite pot nazaj, ki ni odvisna od poti, ki jo spreminjate. Nato odprite drugo upravljalno sejo ob preskusu VPN: prej vzpostavljena lahko preživi pravilo, ki blokira nove. Zapišite oba lastnika politik, da nobena ponovna gradnja ne obnovi polovice poti; če se obe plasti strinjata in tunel še vedno ne deluje, zajemite na vmesniku gosta in preverite naslov in vrata, ki jih odjemalec res uporablja.