Miksi reitittimen ylläpito lakkaa vastaamasta VPN-muutoksen jälkeen

Muutit reittiä tai palomuurisääntöä testataksesi tunnelia reitittimellä, ja nyt hallintasivu ei vastaa kannettavasta, joka toimi kymmenen minuuttia aiemmin moitteettomasti. Refleksi on syyttää VPN:ää. Useimmiten tunneli on kunnossa ja jokin kolmesta muusta meni rikki: reitti takaisin reitittimen omaan osoitteeseen puuttuu, syöttökäytäntö pudottaa pyynnön tai verkkopalvelu ei kuuntele osoitetta, jota kutsut. Kaikki kolme näyttävät selaimessa samalta, siksi ihmiset käynnistävät tunnelia uudelleen tunnin ja oppivat mitään.

Tässä myytti, joka kannattaa tappaa ensimmäisenä: toimiva tunneli ei ole tie takaisin sisään. Se on uusi verkkoliitäntä, jolla on omat luottamuskysymyksensä, ja se voi hiljaa poistaa vanhan hallintapolun samalla kun se avaa uuden, jota kukaan ei tarkistanut.

Tunneli ei ollut koskaan hallintapolku

Edelleenlähetys ja syöttö ovat eri töitä. ”Voiko asiakas päästä NASiin tunnelin kautta?” on edelleenlähetyskysymys reitittimen läpi kulkevista paketeista. ”Voinko avata reitittimen SSH-portin?” on syöttökysymys reitittimelle itselleen osoitetuista paketeista. Edelleenlähetetylle liikenteelle kirjoitettu sallintasääntö ei tee toiselle kysymykselle mitään, ja se on yleisin syy siihen, miksi tunneli, joka kuljettaa liikennettä moitteettomasti, silti hylkää hallintaistuntosi.

Vastakkainen virhe on luottaa liitännän nimeen. Tunneli salataan vertaiselle, ei jokaiselle sen takana olevalle palvelulle, eikä liitännän tunnisteessa oleva sana VPN kerro mitään siitä, mille lähteille kirjautuminen pitäisi sallia.

Ensimmäinen kerros: onko reitti reitittimen omaan osoitteeseen?

Aloita asiakkaalta ja kysy ytimeltä, minne paketti menee. Linuxissa ip route get 10.6.0.1 tulostaa valitun reitin, lähtevän liitännän ja lähdeosoitteen. Jos se ilmoittaa oletusreitistä palveluntarjoajallesi, paketti ei koskaan päädy tunneliin, eikä mikään reitittimen sääntö voi pelastaa sitä.

Tunnelin puolella on oma versionsa kysymyksestä. WireGuard käsittelee AllowedIPs-listaa salausavainten reititystauluna: kummassakin päässä se ilmoittaa, mitä lähdeosoitteita vertais saa käyttää ja mitkä kohteet lähetetään sille vertaiselle. Jos asiakkaan merkintä ei sisällä reitittimen tunneliosoitetta, asiakkaalla ei ole reittiä sinne. Jos palvelimen merkintä kyseiselle asiakkaalle ei kata asiakkaan tunneliosoitetta, palvelin pudottaa paketin ennen kuin yhtäkään palomuurisääntöä katsotaan.

Vahvista tarkka osoite, johon odotat pääseväsi, ennen kuin alat selvittää käytäntöä. Vanhentunut DNS-tietue tai ennen muutosta välimuistiin jäänyt naapurimerkintä vie sinut osoitteeseen, joka ei ollut koskaan reitittimen.

Toinen kerros: syöttökäytäntö, ei edelleenlähetyskäytäntö

Palomuurit arvioivat sääntöjä liitännällä, jolla paketti saapuu. pfSensessä ja OPNsensessä liitännän välilehti ja sääntöjen järjestys ratkaisevat, sallitaanko liikenne palomuurin omiin palveluihin; sääntö, joka päästää LAN-asiakkaat internetiin, ei ole sääntö, joka sallii tunnelin vertaisen avata verkkokäyttöliittymän. OpenWrt:ssä firewall4:n kanssa jokainen vyöhyke kantaa syöttökäytäntöä, option input 'ACCEPT' tai 'REJECT', ja tunneliliitäntä vyöhykkeellä, jonka syöttö on REJECT, hylkää hallintayhteydet samalla kun se vielä välittää liikennettä, jos edelleenlähetys on sallittua.

Älä poista lukkiutumisen estävää sääntöä käytöstä saadaksesi uuden polun toimimaan. Se sääntö estää huonoa sääntöä lukitsemasta LAN-hallintaosoitetta; se suojaa LAN-aliverkkoa, ei juuri luotua tunnelialiverkkoa. Lisää yksi kapea sääntö ylläpitäjän lähteelle ja jätä turvaverkko rauhaan. pfSensen hallintakäyttöoikeuksien dokumentaatio kertoo, missä nämä säätimet ovat.

# 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 kerros: kuunteleeko osoitteella ylipäätään mikään?

Palvelu voi olla käynnissä ja silti tavoittamaton, koska se sitoutui yhteen osoitteeseen. OpenWrt:n uhttpd pitää nimenomaisia kuuntelumerkintöjä tiedostossa /etc/config/uhttpd, esimerkiksi list listen_http '0.0.0.0:80'; koontiversio, joka sitoutuu vain LAN-osoitteeseen, ei ota mitään vastaan tunneliosoitteella, ja tuotteet, jotka tarjoavat kuunteluliitännän asetuksen, käyttäytyvät samoin. Yllä olevat kuuntelukomennot vastaavat tähän suoraan.

Erottele sitten torjunta hiljaisuudesta. nc -vz 10.6.0.1 443, joka palauttaa torjutun yhteyden, tarkoittaa, että paketti saavutti reitittimen ja jokin torjui sen, joko suljettu portti tai nimenomainen torjuntassääntö. Riippuminen aikakatkaisuun tarkoittaa, että paketti pudotettiin tai sitä ei koskaan reititetty. Tämä ero kertoo, mitä kerrosta tutkia seuraavaksi, ja se maksaa viisi sekuntia.

VPN-liitäntä on raja, ei palautumispolku

Salaus suojaa johdon; se ei kerro mitään siitä, kuka saa avata hallintasivun. Kun tunneli toimii, vastusta kiusausta ratkaista tavoitettavuus sallimalla kaikki tunneliliitännällä. Anna ylläpitäjille sääntö, joka on sidottu heidän omaan tunneliosoitteeseensa, tai erillinen vain ylläpitäjille tarkoitettu tunneli, ja pidä tavalliset käyttäjät, NAS, kamerat ja perheen kannettavat hallintaportin ulkopuolella. Vertaisen, joka tarvitsee tiedostojen jakamista, ei pitäisi olla yhden säännön päässä reitittimen kirjautumisesta.

Reitittimen rooli muuttaa vastausta. Tunnelin päättävä reititin voi perustellusti hyväksyä ylläpitäjiä sen kautta, kun taas reititin, joka käyttää tunnelia vain internetin ulostulona, ei yleensä pitäisi. Kummassakin tapauksessa aliverkon lupa ei ole kirjautuminen, joten pidä tilin todennus ja kuljetuksen turvallisuus käytössä.

Kompensointiliike, jonka ihmiset tekevät lukkiutumisen jälkeen, on pahempi: WAN-hallinnan käyttöönotto tai portin edelleenlähetys verkkokäyttöliittymään. Se muuttaa lyhyen katkoksen pysyväksi altistumiseksi, ja kirjautumissivu on silloin jokaisen internetin skannerin tavoitettavissa. Testaa myös kielletty puoli, ei vain sallittu, jotta vertais, jolla ei pitäisi olla hallintakäyttöoikeutta, saa aikakatkaisun tai torjunnan kirjautumiskehotteen sijaan.

Testaa myös tuoreella yhteydellä. Tilallinen palomuuri pitää olemassa olevat vuot tilataulussaan, joten jo avoinna oleva SSH-istunto voi selvitä muutoksesta, joka estää jokaisen uuden yhteyden. Näin lukkiutuminen pysyy näkymättömänä seuraavaan uudelleenkäynnistykseen tai kannettavan seuraavaan uneen asti.

Valmistele paluutie ennen kuin kosket käytäntöön

Kirjoita neljä asiaa ennen ensimmäistä muutosta: miten pääset laitteeseen, jos tunneli kuolee, esimerkiksi sarjakonsolin, palveluntarjoajan konsolin tai LANissa olevan koneen kautta; minne nykyinen kokoonpano viedään; mitä yksittäistä sääntöä tai reittiä aiot muuttaa; ja miten palautat juuri kyseisen kohteen. OpenWrt:ssä sysupgrade -b /tmp/backup.tar.gz kaappaa kokoonpanon, ja muutokset pysyvät odottavina kunnes uci commit, mikä antaa halvan kumoamisen, jos huomaat ajoissa. pfSense pitää kokoonpanohistoriaa, ja AutoConfigBackup auttaa vain, jos se oli jo käytössä. Jos reititin käyttää fail-closed-sääntöjoukkoa, varmista, että suunnittelemasi huoltotie ei ole sen säännön estämän liikenteen sisällä, ja muista, että uudelleenkäynnistys soveltaa pysyvät säännöt uudelleen sen sijaan että tyhjentäisi ne.

Muuta yhtä rajaa yritystä kohden ja testaa sitten uudesta yhteydestä sen sijaan että käyttäisit avoinna pitämääsi komentotulkkiin. Jos testi epäonnistuu, kumoa se yksi muutos ennen kuin kosket seuraavaan kerrokseen. Tunneli voi pysyä pystyssä koko ajan, mutta sen vihreä tilakuvake ei ole todiste siitä, että pääset vielä sisään.

Pikatarkistus ennen lähtöä:

• Pääsetkö reitittimelle lähteestä, joka ei riipu juuri muuttamastasi säännöstä?
• Salliiko tunneliliitännän syöttökäytäntö vain ylläpitäjän lähteen?
• Onko hallintapalvelu sidottu osoitteeseen, joka on olemassa tunnelilla?
• Oletko testannut yhtä kiellettyä vertaista ja yhtä tuoretta istuntoa?
• Onko WAN-hallintapinta edelleen suljettu?