Miks ruuteri haldus lakkab pärast VPN-i muudatust vastamast

Muutsite marsruuti või tulemüürireeglit, et ruuteril tunnelit testida, ja nüüd ei vasta haldusleht sülearvutist, mis kümme minutit varem töötas korralikult. Refleks on süüdistada VPN-i. Enamikul juhtudel on tunnel terve ja katki läks üks kolmest muust asjast: puudub marsruut tagasi ruuteri enda aadressile, sisendpoliitika viskab päringu ära või veebiteenus ei kuula aadressi, millele helistate. Kõik kolm näevad brauseris ühesugused välja, seepärast taaskäivitavad inimesed tunnelit tund aega ega õpi midagi.

Siin on müüt, mille tasub kõigepealt tappa: töötav tunnel ei ole tee tagasi sisse. See on uus võrguühendus oma usaldusküsimustega ja võib vaikselt eemaldada teie vana haldustee, avades samal ajal uue, mida keegi ei vaadanud.

Tunnel ei olnud kunagi haldustee

Edastamine ja sisend on erinevad tööd. „Kas klient pääseb tunnelist NAS-ile?“ on edastamisküsimus ruuterist läbi minevate pakettide kohta. „Kas ma saan avada ruuteri SSH-pordi?“ on sisendküsimus ruuterile endale adresseeritud pakettide kohta. Edastatud liikluse jaoks kirjutatud lubamisreegel ei tee teise küsimuse jaoks midagi ja see on kõige levinum põhjus, miks tunnel, mis kannab liiklust laitmatult, ikkagi teie haldusseansi tagasi lükkab.

Vastupidine viga on usaldada liidese nime. Tunnel on krüpteeritud partnerini, mitte iga teenuseni selle taga, ja sõna VPN liidese siltil ei ütle midagi selle kohta, millistel allikatel peaks olema lubatud sisse logida.

Esimene kiht: kas ruuteri enda aadressile on marsruut?

Alustage kliendil ja küsige tuumalt, kuhu pakett läheb. Linuxis trükib ip route get 10.6.0.1 valitud marsruudi, väljuva liidese ja lähteaadressi. Kui see teatab vaikimisi marsruudist teie teenusepakkuja suunas, ei satu pakett kunagi tunnelisse ja ükski ruuteri reegel ei päästa seda.

Tunneli poolel on küsimusest oma versioon. WireGuard käsitleb AllowedIPs-i krüptovõtme marsruutimistabelina: kummalgi otsal teatab see, milliseid lähteaadresse partner tohib kasutada ja millised sihtkohad sellele partnerile saadetakse. Kui kliendi kirje ei sisalda ruuteri tunneli aadressi, ei ole kliendil sinna marsruuti. Kui serveri kirje selle kliendi jaoks ei kata kliendi tunneli aadressi, viskab server paketi ära enne, kui ühtegi tulemüürireeglit vaadatakse.

Kinnitage täpne aadress, mida loodate saavutada, enne poliitika silumist. Aegunud DNS-kirje või enne muudatust vahemällu jäänud naaberkirje viib teid aadressile, mida ruuteril kunagi ei olnud.

Teine kiht: sisendpoliitika, mitte edastuspoliitika

Tulemüürid hindavad reegleid liidesel, kuhu pakett saabub. pfSense'is ja OPNsense'is otsustavad liidese vahekaart ja reeglite järjekord, kas liiklus tulemüüri enda teenustesse on lubatud; reegel, mis laseb LAN-kliendid internetti, ei ole reegel, mis lubab tunneli partneril veebiliidest avada. OpenWrt-is firewall4-ga kannab iga tsoon sisendpoliitikat, option input 'ACCEPT' või 'REJECT', ja tsooni, mille sisend on REJECT, tunneliliides keeldub haldusühendustest, edastades samal ajal liiklust, kui edastamine on lubatud.

Ärge lülitage lukustusvastast reeglit välja, et uus tee töötaks. See reegel hoiab ära LAN-i haldusaadressi lukustamise halva reegli tõttu; see kaitseb LAN-i alavõrku, mitte teie äsja loodud tunneli alavõrku. Lisage üks kitsas reegel administraatori allika jaoks ja jätke turvavõrk rahule. pfSense'i haldusjuurdepääsu dokumentatsioon selgitab, kus need juhtimisvahendid asuvad.

# 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

Kolmas kiht: kas sellel aadressil kuulab üldse miski?

Teenus võib töötada ja olla ikkagi kättesaamatu, sest see seoti ühe aadressiga. OpenWrt-i uhttpd hoiab selgesõnalisi kuulamis kirjeid failis /etc/config/uhttpd, näiteks list listen_http '0.0.0.0:80'; buut, mis seotakse ainult LAN-i aadressiga, ei võta tunneliaadressil midagi vastu, ja tooted, mis pakuvad kuulamisliidese seadet, käituvad samamoodi. Ülaltoodud kuulamis käsud vastavad sellele otse.

Seejärel eraldage keeldumine vaikusest. nc -vz 10.6.0.1 443, mis tagastab keeldutud ühenduse, tähendab, et pakett jõudis ruuterini ja miski lükkas selle tagasi, kas suletud port või selgesõnaline keeldumisreegel. Rippumine kuni aegumiseni tähendab, et pakett visati ära või seda ei marsruuditud kunagi. See erinevus ütleb, millist kihti järgmisena uurida, ja see maksab viis sekundit.

VPN-liides on piir, mitte taastamistee

Krypteerimine kaitseb juhet; see ei ütle midagi selle kohta, kes tohib halduslehe avada. Kui tunnel töötab, vastu pidage kiusatusele lahendada kättesaadavus, lubades tunneliliidesel kõike. Andke administraatoritele reegel, mis on seotud nende enda tunneli aadressiga, või eraldi ainult administraatorite tunnel, ja hoidke tavalised kasutajad, NAS, kaamerad ja pere sülearvutid haldusportist eemal. Partner, kes vajab failijagamist, ei tohiks olla ühe reegli kaugusel ruuteri sisselogimisest.

Ruuteri roll muudab vastust. Tunnelit lõpetav ruuter võib seaduslikult administraatoreid sealt vastu võtta, samas kui ruuter, mis kasutab tunnelit ainult internetiväljapääsuna, tavaliselt ei peaks. Mõlemal juhul ei ole alavõrgu luba sisselogimine, nii et jätke kontode autentimine ja transpordi turvalisus sisse lülitatuks.

Kompenseeriv käik, mida inimesed pärast lukustust teevad, on hullem: WAN-halduse sisse lülitamine või pordi edastamine veebiliidesele. See muudab lühikese katkestuse alaliseks paljastumiseks ja sisselogimisleht on siis kättesaadav igale interneti skannerile. Testige ka keelatud poolt, mitte ainult lubatud poolt, et partner, kellel ei tohiks olla haldusjuurdepääsu, saaks aegumise või keeldumise sisselogimisküsimise asemel.

Testige ka värske ühendusega. Olekupõhine tulemüür hoiab olemasolevaid voogusid oma olekutabelis, nii et juba avatud SSH-seanss võib üle elada muudatuse, mis blokeerib iga uue ühenduse. Nii jääb lukustus nähtamatuks kuni järgmise taaskäivituse või sülearvuti järgmise uneni.

Valmistage tagasitee ette enne, kui poliitikat puudutate

Kirjutage enne esimest muudatust üles neli asja: kuidas te seadmeni jõuate, kui tunnel sureb, näiteks jadakonooli, teenusepakkuja konsooli või LAN-is asuva masina kaudu; kuhu praegune konfiguratsioon eksporditakse; millist üksikut reeglit või marsruuti te kavatsete muuta; ja kuidas te täpselt selle üksuse tagasi pöörate. OpenWrt-is jäädvustab sysupgrade -b /tmp/backup.tar.gz konfiguratsiooni ja muudatused jäävad ootele kuni uci commit, mis annab teile odava tagasivõtmise, kui märkate õigel ajal. pfSense peab konfiguratsiooni ajalugu ja AutoConfigBackup aitab ainult siis, kui see oli juba sisse lülitatud. Kui ruuter kasutab fail-closed reeglistikku, kinnitage, et kavandatud hooldustee ei ole selle reegli blokeeritava liikluse sees, ja pidage meeles, et taaskäivitamine rakendab püsireeglid uuesti, mitte ei kustuta neid.

Muutke ühte piiri katse kohta, seejärel testige uuest ühendusest, mitte kestast, mida lahti hoiate. Kui test ebaõnnestub, pöörake see üks muudatus tagasi enne järgmise kihi puudutamist. Tunnel võib jääda kogu aeg üles, kuid selle roheline olekuikoon ei ole tõestus, et te veel sisse pääsete.

Kiire kontroll enne lahkumist:

• Kas pääsete ruuterini allikast, mis ei sõltu reeglist, mida just muutsite?
• Kas tunneliliidese sisendpoliitika lubab ainult administraatori allikat?
• Kas haldusteenus on seotud aadressiga, mis tunnelis olemas on?
• Kas testisite üht keelatud partnerit ja üht värsket seanssi?
• Kas WAN-halduse pind on endiselt suletud?