Zašto administratorski pristup ruteru prestaje odgovarati nakon promjene VPN-a

Promijenili ste rutu ili pravilo firewalla da testirate tunel na ruteru, a sada se administratorska stranica ne odaziva s laptopa koji je prije deset minuta radio ispravno. Prva reakcija je kriviti VPN. Većinu vremena tunel je zdrav i pokvarila se jedna od tri druge stvari: nema rute natrag na vlastitu adresu rutera, ulazna politika odbacuje zahtjev ili web usluga ne sluša adresu koju pozivate. Sve tri izgledaju isto u pregledniku, zato ljudi sat vremena restarta tunel i ništa ne nauče.

Evo mita koji prvo vrijedi ubiti: tunel koji radi nije put natrag unutra. To je novi mrežni priključak s vlastitim pitanjima povjerenja i može tiho ukloniti vaš stari put upravljanja dok otvara novi koji nitko nije pregledao.

Tunel nikada nije bio put upravljanja

Prosljeđivanje i ulaz su različiti poslovi. "Može li klijent doći do NAS-a kroz tunel?" je pitanje prosljeđivanja o paketima koji prolaze kroz ruter. "Mogu li otvoriti SSH port rutera?" je pitanje ulaza o paketima upućenima samom ruteru. Pravilo propuštanja napisano za proslijeđeni promet ne čini ništa za drugo pitanje, i to je najčešći razlog zašto tunel koji savršeno nosi promet ipak odbija vašu administratorsku sesiju.

Obrnuta greška je vjerovati imenu sučelja. Tunel je šifriran prema partneru, a ne prema svakoj usluzi iza njega, a riječ VPN u oznaci sučelja ne govori ništa o tome kojim izvorima treba dopustiti prijavu.

Prvi sloj: postoji li ruta do vlastite adrese rutera?

Počnite na klijentu i pitajte kernel kamo će paket ići. Na Linuxu ip route get 10.6.0.1 ispisuje odabranu rutu, izlazno sučelje i izvornu adresu. Ako prijavljuje zadanu rutu prema vašem ISP-u, paket nikada ne ulazi u tunel i nijedno pravilo na ruteru ga ne može spasiti.

Strana tunela ima svoju verziju pitanja. WireGuard tretira AllowedIPs kao tablicu usmjeravanja kriptoključa: na svakom kraju objavljuje koje izvorne adrese partner smije koristiti i koja odredišta se šalju tom partneru. Ako klijentski zapis ne uključuje tunelsku adresu rutera, klijent nema rutu do nje. Ako serverski zapis za tog klijenta ne pokriva tunelsku adresu klijenta, server odbacuje paket prije nego što se pogleda ijedno pravilo firewalla.

Potvrdite točnu adresu koju očekujete dosegnuti prije otklanjanja problema u politici. Zastario DNS zapis ili predmemorirani zapis susjeda od prije promjene vodi vas na adresu koju ruter nikada nije posjedovao.

Drugi sloj: ulazna politika, a ne politika prosljeđivanja

Firewallovi ocjenjuju pravila na sučelju na koje paket dolazi. Na pfSenseu i OPNsenseu kartica sučelja i redoslijed pravila odlučuju je li promet prema vlastitim uslugama firewalla dopušten; pravilo koje pušta LAN klijente na internet nije pravilo koje dopušta partneru tunela otvaranje web GUI-ja. Na OpenWrtu s firewall4 svaka zona nosi ulaznu politiku, option input 'ACCEPT' ili 'REJECT', a tunelsko sučelje u zoni s ulazom REJECT odbijat će upravljačke veze dok još uvijek prosljeđuje promet ako je prosljeđivanje dopušteno.

Ne isključujte pravilo protiv zaključavanja da bi novi put proradio. To pravilo čuva LAN upravljačku adresu od zaključavanja lošim pravilom; ono štiti LAN podmrežu, a ne tunelsku podmrežu koju ste upravo stvorili. Dodajte jedno usko pravilo za izvor administratora i ostavite sigurnosnu mrežu na miru. pfSense dokumentacija o administratorskom pristupu objašnjava gdje se nalaze te kontrole.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Treći sloj: sluša li išta na toj adresi?

Usluga može raditi i dalje biti nedostupna jer se vezala na jednu adresu. OpenWrtov uhttpd drži izričite zapise slušanja u /etc/config/uhttpd, na primjer list listen_http '0.0.0.0:80'; gradnja koja se veže samo na LAN adresu ne prihvaća ništa na tunelskoj adresi, a proizvodi koji izlažu postavku sučelja za slušanje ponašaju se isto. Gornje naredbe za slušanje odgovaraju na to izravno.

Zatim odvojite odbijanje od tišine. nc -vz 10.6.0.1 443 koja vraća odbijenu vezu znači da je paket stigao do rutera i da ga je nešto odbilo, bilo zatvoren port bilo izričito pravilo odbijanja. Visanje do isteka vremena znači da je paket odbačen ili nikada usmjeren. Ta razlika vam kaže koji sloj sljedeće pregledati i košta pet sekundi.

VPN sučelje je granica, a ne put oporavka

Šifriranje štiti žicu; ne govori ništa o tome kome je dopušteno otvoriti administratorsku stranicu. Kad tunel proradi, oduprite se porivu da dostupnost riješite dopuštanjem svega na tunelskom sučelju. Dajte administratorima pravilo vezano uz njihovu vlastitu tunelsku adresu ili zaseban tunel samo za administratore, i držite obične korisnike, NAS, kamere i obiteljske laptope podalje od upravljačkog porta. Partner koji treba dijeljenje datoteka ne smije biti jedno pravilo udaljen od prijave na ruter.

Uloga rutera mijenja odgovor. Ruter koji završava tunel može legitimno prihvaćati administratore iz njega, dok ruter koji tunel koristi samo kao izlaz na internet obično ne bi trebao. U oba slučaja dopuštenje podmreže nije prijava, zato držite autentifikaciju računa i sigurnost prijenosa uključenima.

Kompenzacijski potez koji ljudi naprave nakon zaključavanja je gori: uključivanje WAN administracije ili prosljeđivanje porta na web GUI. To kratki prekid pretvara u trajnu izloženost, a stranica za prijavu tada je dostupna svakom skeneru na internetu. Testirajte i odbijenu stranu, ne samo dopuštenu, tako da partner koji ne bi smio imati administratorski pristup dobije istek vremena ili odbijenicu umjesto upita za prijavu.

Testirajte i svježom vezom. Stateful firewall drži postojeće tokove u svojoj tablici stanja, pa vaša već otvorena SSH sesija može preživjeti promjenu koja blokira svaku novu vezu. Tako zaključavanje ostaje nevidljivo do sljedećeg restarta ili sljedećeg spavanja laptopa.

Pripremite put natrag prije nego dirnete politiku

Zapišite četiri stvari prije prve promjene: kako ćete doći do uređaja ako tunel umre, poput serijske konzole, konzole davatelja usluge ili stroja na LAN-u; kamo se izvozi trenutačna konfiguracija; koje jedno pravilo ili rutu ćete izmijeniti; i kako ćete vratiti točno tu stavku. Na OpenWrtu sysupgrade -b /tmp/backup.tar.gz snima konfiguraciju, a izmjene ostaju na čekanju do uci commit, što vam daje jeftin poništaj ako na vrijeme primijetite. pfSense drži povijest konfiguracije, a AutoConfigBackup pomaže samo ako je već bio uključen. Ako ruter radi sa skupom pravila fail-closed, potvrdite da planirani put za održavanje nije unutar prometa koji to pravilo blokira i zapamtite da restart ponovno primjenjuje trajna pravila umjesto da ih briše.

Mijenjajte jednu granicu po pokušaju, zatim testirajte s nove veze, a ne iz ljuske koju držite otvorenom. Ako test ne uspije, vratite tu jednu promjenu prije nego dirnete sljedeći sloj. Tunel može ostati podignut cijelo vrijeme, ali njegova zelena ikona stanja nije dokaz da još možete ući.

Brza provjera prije nego odete:

• Možete li doći do rutera s izvora koji ne ovisi o pravilu koje ste upravo uredili?
• Dopušta li ulazna politika na tunelskom sučelju samo izvor administratora?
• Je li upravljačka usluga vezana na adresu koja postoji na tunelu?
• Jeste li testirali jednog odbijenog partnera i jednu svježu sesiju?
• Je li WAN administratorska površina još uvijek zatvorena?