Hvers vegna hættir stjórnborð beinbrautarinnar að svara eftir VPN-breytingu

Þú breyttir leið eða eldveggjarreglu til að prófa göng á beinbrautinni, og nú svarar stjórnborðið ekki frá fartölvunni sem virkaði vel fyrir tíu mínútum. Viðbragðið er að kenna VPN-inu um. Oftast er göngin heilbrigð og eitt af þremur öðrum hlutum hefur bilað: engin leið aftur að eigin vistfangi beinbrautarinnar, inntaksstefna hendir beiðninni, eða veffþjónusta hlustar ekki á vistfangið sem þú hringir í. Þrjú þeirra líta eins út í vafranum, þess vegna endurræsa menn göngin í klukkustund og læra ekkert.

Hér er goðsögnin sem er þess virði að drepa fyrst: virk göng eru ekki leið aftur inn. Þau eru ný nettenging með eigin traustsspurningum, og geta í hljóði fjarlægt gamla stjórnslóðina þína á meðan þau opna nýja sem enginn fór yfir.

Göngin voru aldrei stjórnslóðin

Framleiðsla og inntak eru ólík verk. „Getur biðlari náð í NAS í gegnum göngin?“ er framleiðsluspurning um pakka sem fara í gegnum beinbrautina. „Get ég opnað SSH-port beinbrautarinnar?“ er inntaksspurning um pakka sem eru stílaðir á beinbrautina sjálfa. Leyfisregla sem er skrifuð fyrir framleidda umferð gerir ekkert fyrir seinni spurninguna, og það er algengasta ástæðan fyrir því að göng sem flytja umferð fullkomlega hafna samt stjórnlotunni þinni.

Öfug mistök eru að treysta viðmótsnafni. Göng eru dulrituð til jafningjans, ekki til hverrar þjónustu á bak við þau, og orðið VPN á viðmótsmerki segir ekkert um hvaða upptökum eigi að vera leyft að skrá sig inn.

Fyrsta lag: er leið að eigin vistfangi beinbrautarinnar?

Byrjaðu á biðlaranum og spurðu kjarnann hvert pakkinn muni fara. Á Linux prentar ip route get 10.6.0.1 valda leið, útgangsviðmótið og upprunavistfangið. Ef það tilkynnir sjálfgefnu leiðina í átt að þjónustuveitunni þinni kemst pakkinn aldrei inn í göngin, og engin regla á beinbrautinni getur bjargað honum.

Gönguhliðin hefur sína eigin útgáfu af spurningunni. WireGuard meðhöndlar AllowedIPs sem dulritunarlyklaleiðartöflu: á hvorum enda lýsir hún því hvaða upprunavistföng jafningi má nota og hvaða áfangastaðir eru sendir til þess jafnings. Ef biðlarafærslan inniheldur ekki gönguvistfang beinbrautarinnar hefur biðlarinn enga leið þangað. Ef netþjónsfærslan fyrir þann biðlara nær ekki yfir gönguvistfang biðlarans hendir netþjónninn pakkanum áður en nokkur eldveggjarregla er skoðuð.

Staðfestu nákvæmlega það vistfang sem þú býst við að ná í áður en þú kembir stefnuna. Úrelt DNS-færsla eða skyldmennisfærsla í skyndiminni frá því fyrir breytinguna sendir þig á vistfang sem beinbrautin hefur aldrei átt.

Annað lag: inntaksstefnan, ekki framleiðslustefnan

Eldveggir meta reglur á því viðmóti sem pakkinn kemur inn á. Í pfSense og OPNsense ráða viðmótsflipi og röð reglna hvort umferð til eigin þjónustu eldveggjarins sé leyfð; regla sem hleypir LAN-biðlarum út á netið er ekki regla sem leyfir jafningi gagnanna að opna vefviðmótið. Í OpenWrt með firewall4 ber hver svæði inntaksstefnu, option input 'ACCEPT' eða 'REJECT', og gönguviðmót í svæði með inntakið REJECT mun synja stjórntengingum á meðan það framleiðir enn umferð ef framleiðsla er leyfð.

Slaktu ekki læsingarvarnarreglunni til að láta nýju leiðina virka. Sú regla kemur í veg fyrir að slæm regla læsi LAN-stjórnvistfanginu; hún verndar LAN-undirnetið, ekki gönguundirnetið sem þú varst að búa til. Bættu við einni þröngri reglu fyrir upptök stjórnandans og láttu öryggisnetið vera. pfSense fylgiskjölin um stjórnandaðgang útskýra hvar þessar stýringar eru.

# 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

Þriðja lag: hlustar eitthvað á því vistfangi?

Þjónusta getur verið í gangi og samt verið óaðgengileg því hún bundist einu vistfangi. uhttpd OpenWrt heldur skýrum hlustunarfærslum í /etc/config/uhttpd, til dæmis list listen_http '0.0.0.0:80'; smíð sem bindst aðeins LAN-vistfanginu tekur við engu á gönguvistfanginu, og vörur sem sýna stillingu hlustunarviðmóts hegða sér eins. Hlustunarskipanirnar að ofan svara þessu beint.

Þá skaltu aðskilja synjun frá þögn. nc -vz 10.6.0.1 443 sem skilar synjaðri tengingu þýðir að pakkinn náði beinbrautinni og eitthvað synjaði honum, annaðhvort lokuð höfn eða skýr synjunarregla. Hangandi þar til tíminn rennur út þýðir að pakkinn var hent eða aldrei beint. Sá munur segir þér hvaða lag á að skoða næst, og hann kostar fimm sekúndur.

VPN-viðmót er mörk, ekki endurheimtuleið

Dulritun verndar vírinn; hún segir ekkert um hver má opna stjórnborðið. Þegar göngin virka skaltu standa gegn hvötinni að leysa aðgengi með því að leyfa allt á gönguviðmótinu. Gefðu stjórnendum reglu sem er bundin eigin gönguvistfangi þeirra eða sérstök göng aðeins fyrir stjórnendur, og haltu venjulegum notendum, NAS-inu, myndavélunum og fartölvum fjölskyldunnar fjarri stjórnportinu. Jafningi sem þarf skráardeilingu ætti ekki að vera einni reglu frá innskráningu beinbrautarinnar.

Hlutverk beinbrautarinnar breytir svarinu. Beinbraut sem lýkur göngunum má lögmætlega taka við stjórnendum úr þeim, en beinbraut sem notar göngin aðeins sem útgang á netið ætti venjulega ekki að gera það. Í báðum tilvikum er undirnetsleyfið ekki innskráningin, svo hafðu reikningsauðkenningu og flutningsöryggi virk.

Uppbótarskrefið sem fólk tekur eftir læsingu er verra: að kveikja á WAN-stjórnun eða framleiða port á vefviðmótið. Það breytir stuttu niðurfalli í varanlega vá, og innskráningarsíðan verður þá aðgengileg hverjum skanna á netinu. Prófaðu líka hina synjuðu hlið, ekki bara hina leyfðu, svo jafningi sem á ekki að hafa stjórnandaaðgang fái tímatakmörk eða synjun í stað innskráningarbeiðni.

Prófaðu líka með nýrri tengingu. Ástandsmeðvitaður eldveggur heldur núverandi streymum í ástandstöflunni, svo SSH-lotan sem þú hefur þegar opnað getur lifað breytingu sem lokar fyrir hverja nýja tengingu. Þannig verður læsing ósýnileg þar til næsta endurræsing eða næsta svefn fartölvunnar.

Undirbúðu leiðina til baka áður en þú snertir stefnuna

Skrifaðu niður fjóra hluti fyrir fyrstu breytinguna: hvernig þú nálgast tækið ef göngin deyja, til dæmis raðtengi, þjónustuveitukonsóll eða vél á LAN-inu; hvert núverandi stilling er flutt út; hvaða einu reglu eða leið þú ætlar að breyta; og hvernig þú veltir nákvæmlega þeim lið til baka. Í OpenWrt fangar sysupgrade -b /tmp/backup.tar.gz stillinguna, og breytingar bíða þar til uci commit, sem gefur þér ódýra afturköllun ef þú tekur eftir í tæka tíð. pfSense heldur stillingarsögu, og AutoConfigBackup hjálpar aðeins ef það var þegar virkt. Ef beinbrautin keyrir fail-closed reglusett skaltu staðfesta að viðhaldsleiðin sem þú skipulagðir sé ekki inni í þeirri umferð sem reglan lokar á, og mundu að endurræsing beitir varanlegum reglum aftur í stað þess að hreinsa þær.

Breyttu einum mörkum í hvert skipti og prófaðu svo frá nýrri tengingu í stað skeljarinnar sem þú heldur opinni. Ef prófið mistekst skaltu velta þeirri einu breytingu til baka áður en þú snertir næsta lag. Göngin geta verið uppi allan tímann, en grænt stöðutákn þeirra er ekki sönnun þess að þú komist enn inn.

Hraðathugun áður en þú ferð:

• Nærðu beinbrautinni frá upptökum sem ekki eru háð reglunni sem þú varst að breyta?
• Leyfir inntaksstefnan á gönguviðmótinu aðeins upptök stjórnandans?
• Er stjórnunarþjónustan bundin vistfangi sem er til á göngunum?
• Prófaðir þú einn synjaðan jafning og eina nýja lotu?
• Er WAN-stjórnunaryfirborðið enn lokað?