VPN je povezan, ali firewall i dalje blokira: kako utvrditi šta je uzrok

Tunel radi, a jedan port i dalje pada. Pročitajte putanju, zatim politiku na svakom sloju i promijenite najužu reglu umjesto da isključite bilo koju od dvije kontrole.

Klijent tvrdi da je povezan, resurs i dalje odbija, a uobičajeni sljedeći potez je isključiti nešto. Dvije kontrole u toj rečenici rade različite poslove: VPN gradi putanju za obuhvaćeni saobraćaj, a firewall odlučuje za svaku vezu smije li saobraćaj proći. Ispravan tunel s politikom koja odbija izgleda korisniku isto kao pokvaren tunel, pa je zadatak naći koji sloj odgovara. Evo reda kojim idem, s čitanjem koje vam kaže da stanete.

Odvojite putanju od politike

Počnite od oblika kvara, jer je to besplatna informacija. Odbacivanje paketa daje tajmaut: klijent ponavlja pokušaj, ništa se ne vraća, a naredba visi dok ne odustane. Odbijanje daje odbijenicu ili reset: nešto je odgovorilo i reklo ne. Servis koji ne sluša odbija na samom hostu, bez ikakvog firewalla.

Ta tri ishoda upućuju na različite slojeve. Tajmaut znači da negdje politika tiho odbacuje, ili ruta nikad ne napušta mašinu. Odbijeno znači da ste stigli do hosta i da je njegov stek ili host firewall odbio. Potpuna tišina, uz podignut interfejs tunela i bez rute do odredišta, znači da je putanja pogrešna i nijedno firewall pravilo to neće popraviti.

Pročitajte putanju u jednom prolazu

Potvrdite da tunel pokriva odredište prije nego pogledate i jedno pravilo. Split tunel koji nosi samo kancelarijsku podmrežu neće usmjeriti zahtjev na drugi opseg, a kvar tada izgleda kao blokada firewalla koja to nije:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Izlaz rute imenuje interfejs kojim će paket otići i izvornu adresu koju će nositi. Ako je taj interfejs vaša fizička mrežna kartica, a ne tunel, problem je u rutiranju ili u dozvoljenim opsezima tunela i pripada VPN konfiguraciji, a ne firewallu.

Jedna zamka specifična za VPN zaslužuje posebnu provjeru. U WireGuardu je AllowedIPs partnera istovremeno ruta i kriptografski filtar: paket čija izvorna adresa ne pripada dozvoljenom skupu partnera odbacuje se prije nego što se pogleda ijedno firewall pravilo. Zato savršeno ispravan host firewall može stajati iza tihog odbacivanja koje izgleda kao politika, a popravka je linija konfiguracije ključa, a ne pravilo.

Pročitajte politiku na sloju koji odgovara

Kad je putanja ispravna, prođite kroz politiku od hosta prema van i gledajte jedini sloj čiji se brojači pomjeraju:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Soket koji sluša odgovara na drugo pitanje nego pravila. Ako ništa ne sluša na portu, kernel odbija vezu i nijedno ulazno pravilo nije relevantno. Ako soket postoji, a veza s udaljenog klijenta istekne, odbacivanje se dešava negdje na putanji, a brojači pravila kažu da li je ovdje.

Uključite logovanje za profil ili lanac koji sumnjate umjesto da nagađate spolja. Jedno zabilježeno odbacivanje koje imenuje izvor, odredište i port identificira sloj i pravilo, a dokazuje i da je paket stigao, što nikakvo testiranje s klijentske strane ne može utvrditi.

Pročitajte odluku mrežnog prolaza kad tunel tamo završava

Na mrežnom prolazu lokacija-lokacija ili udaljenog pristupa VPN autentificira korisnika, a politika odobrava resurs, i to su odvojena odobrenja. Korisnik pušten u tunel nije automatski pušten na svaki interni host, a odbijanje često dolazi od pravila prosljeđivanja dok je sam tunel zdrav. Ista podjela postoji u IPsecu, gdje se sigurnosna politika koja bira saobraćaj razlikuje od filtra koji ga propušta, i zato su ta dva dokumentirana kao različiti mehanizmi u RFC 4301.

Provjerite povratnu putanju jednako pažljivo kao odlaznu. Filtriranje sa stanjem mora vidjeti odgovor, pa asimetrično rutiranje kroz tunel u jednom smjeru i oko njega u drugom daje odbacivanja koja izgledaju slučajno i ponavljaju se samo kod nekih klijenata. Ako saobraćaj stigne do mrežnog prolaza i stane, pročitajte pravilo prosljeđivanja i povratnu rutu zajedno prije nego bilo šta proširite.

Mrežni prolaz je i mjesto gdje NAT ili pravilo maskiranja može sakriti pravi izvor. Ako interni hostovi vide adresu prolaza umjesto klijenta, njihova host firewall pravila koja treba da se poklope s bazenom klijenata nikada se neće poklopiti, a popravka pripada prolazu, a ne svakom serveru.

Promijenite najuži sloj, pa provjerite

Oduprite se širokoj popravci. Isključivanje host firewalla, dodavanje pravila koje dopušta sve ili guranje svakog interfejsa u pouzdani profil — svako od toga uklanja kontrolu koja je radila svoj posao, a promjena nadživi incident. Pravilo ograničeno na izvorni opseg i dotični port lakše je pregledati, lakše ukloniti i ostavlja ostatak politike mašine netaknutim.

Provjerite istim testom koji je pao, s istog klijenta, pa još jednom nakon ponovnog povezivanja, jer pravilo koje se poklapa prije nego tunel ponovo pregovara može prestati da se poklapa poslije:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Prije nego zatvorite:

  • Ruta do odredišta izlazi kroz interfejs tunela, a izvorna adresa se poklapa s onim što politika očekuje.
  • Nešto sluša na portu, a odbijanje ili tajmaut pripisuje se imenovanom pravilu, a ne pretpostavci.
  • Mrežni prolaz prosljeđuje u oba smjera, a odredište vidi izvor za koji su napisana vaša pravila.
  • Nijedna kontrola nije isključena da bi test prošao, a promjena koju ste napravili imenuje jedan izvorni opseg i jedan port.

Povezani članci