VPN je povezan, a požarni zid vseeno blokira: kako ugotoviti, kateri
Predor deluje, ena vrata pa še vedno ne uspejo. Preberite pot, nato politiko na vsakem sloju, in spremenite najožje pravilo, namesto da izklopite eno od dveh kontrol.
Odjemalec pravi, da je povezan, vir še vedno zavrača, in običajni naslednji korak je izklopiti nekaj. Obe kontroli v tem stavku opravljata različno delo: VPN zgradi pot za pokrit promet, požarni zid pa za vsako povezavo odloči, ali promet sme skozi. Delujoč predor z zavračajočo politiko je s stola uporabnika videti natanko kot pokvarjen predor, zato je naloga ugotoviti, kateri sloj odgovarja. To je vrstni red, ki ga sledim, z branjem, ki vam reče, naj se ustavite.
Ločite pot od politike
Začnite z obliko napake, ker je to brezplačna informacija. Opustitev paketa povzroči časovno prekoračitev: odjemalec poskusi znova, nič se ne vrne in ukaz visi, dokler se ne preda. Zavrnitev povzroči zavrnitev ali ponastavitev: nekaj je odgovorilo in reklo ne. Storitev, ki ne posluša, zavrne na samem gostitelju, brez vsakega požarnega zidu.
Ti trije izidi kažejo na različne sloje. Časovna prekoračitev pomeni, da nekje politika tiho zavrže, ali da pot nikoli ne zapusti stroja. Zavrnjeno pomeni, da ste prišli do gostitelja in sta njegov sklad ali krajevni požarni zid rekla ne. Popolna tišina, z dvignjenim vmesnikom predora in brez poti do cilja, pomeni, da je pot napačna in nobeno pravilo požarnega zidu tega ne popravi.
Preberite pot v enem prehodu
Preden pogledate eno samo pravilo, potrdite, da predor pokriva cilj. Razdeljeni predor, ki nosi samo pisarniško podomrežje, ne bo usmeril zahteve v drugo območje, in takrat je napaka videti kot blokada požarnega zidu, ki ni:
ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall
Izhod poti navede vmesnik, skozi katerega bo paket odšel, in izvorni naslov, ki ga bo nosil. Če je ta vmesnik vaša fizična mrežna kartica in ne predor, je težava v usmerjanju ali v dovoljenih območjih predora, in spada k konfiguraciji VPN, ne k požarnemu zidu.
Ena past, značilna za VPN, si zasluži lastno preverjanje. V WireGuardu je AllowedIPs nasprotnega vozlišča hkrati pot in kriptografski filter: paket, katerega izvorni naslov ni v dovoljenem nizu nasprotnega vozlišča, se zavrže, preden se pregleda katerokoli pravilo požarnega zidu. Zato lahko povsem pravilen gostiteljski požarni zid stoji za tihim zavrženjem, ki je videti kot politika, odprava napake pa je vrstica konfiguracije ključa, ne pravilo.
Preberite politiko na sloju, ki odgovarja
Ko je pot pravilna, pojdite skozi politiko od gostitelja navzven in bodite pozorni na edini sloj, katerega števci se premikajo:
ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose
Poslušajoča vtičnica odgovarja na drugo vprašanje kot pravila. Če na vratih nič ne posluša, jedro povezavo zavrne in nobeno vhodno pravilo ni pomembno. Če vtičnica obstaja in povezava z oddaljenega odjemalca poteče, se nekje na poti dogaja zavrženje, in števci pravil povedo, ali se dogaja tu.
Vklopite beleženje za profil ali verigo, ki jo sumite, namesto da ugibate od zunaj. Eno zabeleženo zavrženje, ki navede izvor, cilj in vrata, prepozna sloj in pravilo, in tudi dokaže, da je paket prispel, česar noben test na strani odjemalca ne more ugotoviti.
Preberite odločitev prehoda, ko se predor tam konča
Na prehodu med lokacijama ali pri oddaljenem dostopu VPN overi uporabnika, politika pa odobri vir, in to so ločena dovoljenja. Uporabnik, spuščen v predor, ni samodejno spuščen na vsakega notranjega gostitelja, zavrnitev pa pogosto pride iz pravila posredovanja, medtem ko je predor sam zdrav. Ista ločitev je v IPsec, kjer se varnostna politika, ki izbira promet, razlikuje od filtra, ki ga spusti, in zato sta oba dokumentirana kot različna mehanizma v RFC 4301.
Preverite povratno pot enako skrbno kot odhodno. Filtriranje stanja mora videti odgovor, zato asimetrično usmerjanje skozi predor v eno smer in okoli njega v drugo povzroči zavrženja, ki so videti naključna in se ponovijo le pri nekaterih odjemalcih. Če promet doseže prehod in se ustavi, preberite pravilo posredovanja in povratno pot skupaj, preden karkoli razširite.
Prehod je tudi kraj, kjer lahko pravilo NAT ali prikrivanja skrije pravi izvor. Če notranji gostitelji vidijo naslov prehoda namesto odjemalca, se njihova gostiteljska pravila požarnega zidu, ki bi se morala ujemati s skupino odjemalcev, ne bodo nikoli ujemala, in odprava spada na prehod, ne na vsak strežnik.
Spremenite najožji sloj, nato preverite
Uprite se širokemu popravilu. Izklop gostiteljskega požarnega zidu, dodajanje pravila, ki dovoli vse, ali siljenje vsakega vmesnika v zaupanja vreden profil vsakič odstrani kontrolo, ki je opravljala svoje delo, in sprememba preživi incident. Pravilo, omejeno na izvorno območje in zadevna vrata, je lažje pregledati, lažje odstraniti in pusti preostalo politiko stroja nedotaknjeno.
Preverite z istim testom, ki ni uspel, z istega odjemalca, nato pa še enkrat po ponovni povezavi, ker lahko pravilo, ki se je ujemalo pred ponovnim pogajanjem predora, po njem preneha ujemati:
nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/
Preden to zaprete:
- Pot do cilja zapusti stroj skozi vmesnik predora, izvorni naslov pa se ujema s tem, kar pričakuje politika.
- Na vratih nekaj posluša, in zavrnitev ali časovna prekoračitev je pripisana imenovanemu pravilu, ne predpostavljena.
- Prehod posreduje v obe smeri in cilj vidi izvor, za katerega so bila napisana vaša pravila.
- Nobena kontrola ni bila izklopljena, da bi test uspel, in sprememba, ki ste jo naredili, navede eno izvorno območje in ena vrata.