Kāpēc maršrutētāja administrēšana pārstāj atbildēt pēc VPN maiņas

Jūs mainījāt maršrutu vai ugunsmūra noteikumu, lai maršrutētājā pārbaudītu tuneli, un tagad administrēšanas lapa neatbild no klēpjdatora, kas pirms desmit minūtēm darbojās nevainojami. Pirmā reakcija ir vainot VPN. Visbiežāk tunelis ir vesels, un salūzusi ir viena no trim citām lietām: nav maršruta atpakaļ uz paša maršrutētāja adresi, ievades politika izmet pieprasījumu, vai tīmekļa pakalpojums neklausās adresē, uz kuru jūs zvanāt. Visas trīs pārlūkā izskatās vienādi, tāpēc cilvēki stundu restartē tuneli un neko neiemācās.

Lūk, mīts, ko ir vērts nogalināt vispirms: strādājošs tunelis nav ceļš atpakaļ iekšā. Tā ir jauna tīkla pievienošana ar saviem uzticēšanās jautājumiem, un tā var klusi noņemt jūsu veco pārvaldības ceļu, vienlaikus atverot jaunu, kuru neviens nav pārbaudījis.

Tunelis nekad nav bijis pārvaldības ceļš

Pāradresēšana un ievade ir dažādi darbi. „Vai klients var sasniegt NAS caur tuneli?“ ir pāradresēšanas jautājums par paketēm, kas iet caur maršrutētāju. „Vai es varu atvērt maršrutētāja SSH portu?“ ir ievades jautājums par paketēm, kas adresētas pašam maršrutētājam. Pāradresētajai plūsmai rakstīts atļaujas noteikums otrajam jautājumam neko nedara, un tas ir visbiežākais iemesls, kāpēc tunelis, kas lieliski pārvadā plūsmu, tomēr atsaka jūsu administrēšanas sesiju.

Pretējā kļūda ir uzticēties saskarnes nosaukumam. Tunelis tiek šifrēts līdz partnerim, nevis līdz katram pakalpojumam aiz tā, un vārds VPN saskarnes etiķetē neko nepasaka par to, kuriem avotiem būtu jāļauj pieteikties.

Pirmais slānis: vai ir maršruts uz paša maršrutētāja adresi?

Sāciet klientā un pajautājiet kodolam, kur pakete dosies. Linux sistēmā ip route get 10.6.0.1 izdrukā izvēlēto maršrutu, izejošo saskarni un avota adresi. Ja tas ziņo par noklusējuma maršrutu uz jūsu pakalpojumu sniedzēju, pakete nekad neiekļūst tunelī, un neviens maršrutētāja noteikums to nevar izglābt.

Tuneļa pusei ir sava jautājuma versija. WireGuard AllowedIPs uzskata par šifrēšanas atslēgas maršrutēšanas tabulu: katrā galā tā deklarē, kādas avota adreses partneris drīkst izmantot un kuri galamērķi tiek sūtīti šim partnerim. Ja klienta ieraksts neietver maršrutētāja tuneļa adresi, klientam uz to nav maršruta. Ja servera ieraksts šim klientam neaptver klienta tuneļa adresi, serveris izmet paketi, pirms tiek apskatīts jebkurš ugunsmūra noteikums.

Pirms politikas atkļūdošanas apstipriniet precīzo adresi, kuru cerat sasniegt. Novecojis DNS ieraksts vai kešatmiņā saglabāts kaimiņa ieraksts no laika pirms izmaiņām aizved jūs uz adresi, kas maršrutētājam nekad nav piederējusi.

Otrais slānis: ievades politika, nevis pāradresēšanas politika

Ugunsmūri noteikumus vērtē saskarnē, kurā ierodas pakete. pfSense un OPNsense gadījumā saskarnes cilne un noteikumu secība nosaka, vai plūsma uz pašas ugunsmūra pakalpojumiem ir atļauta; noteikums, kas izlaiž LAN klientus internetā, nav noteikums, kas ļauj tuneļa partnerim atvērt tīmekļa saskarni. OpenWrt ar firewall4 gadījumā katrai zonai ir ievades politika, option input 'ACCEPT' vai 'REJECT', un tuneļa saskarne zonā ar ievadi REJECT atteiks pārvaldības savienojumus, vienlaikus joprojām pāradresējot plūsmu, ja pāradresēšana ir atļauta.

Neizslēdziet pretbloķēšanas noteikumu, lai jaunais ceļš strādātu. Šis noteikums neļauj sliktam noteikumam bloķēt LAN pārvaldības adresi; tas aizsargā LAN apakštīklu, nevis tikko izveidoto tuneļa apakštīklu. Pievienojiet vienu šauru noteikumu administratora avotam un atstājiet drošības tīklu mierā. pfSense administratora piekļuves dokumentācija paskaidro, kur atrodas šīs vadīklas.

# 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šais slānis: vai kaut kas klausās šajā adresē?

Pakalpojums var darboties un tomēr būt nesasniedzams, jo tas piesaistīts vienai adresei. OpenWrt uhttpd uztur skaidrus klausīšanās ierakstus /etc/config/uhttpd, piemēram, list listen_http '0.0.0.0:80'; būvējums, kas piesaistās tikai LAN adresei, neko nepieņem tuneļa adresē, un produkti, kas piedāvā klausīšanās saskarnes iestatījumu, uzvedas tāpat. Iepriekš minētās klausīšanās komandas uz to atbild tieši.

Pēc tam atdaliet atteikumu no klusuma. nc -vz 10.6.0.1 443, kas atgriež atteiktu savienojumu, nozīmē, ka pakete sasniedza maršrutētāju un kaut kas to noraidīja – vai nu aizvērts ports, vai skaidrs atteikuma noteikums. Uzkāršanās līdz taimauta beigām nozīmē, ka pakete tika izmesta vai nekad netika maršrutēta. Šī atšķirība pasaka, kuru slāni pārbaudīt tālāk, un tā maksā piecas sekundes.

VPN saskarne ir robeža, nevis atkopšanas ceļš

Šifrēšana aizsargā vadu; tā neko nepasaka par to, kurš drīkst atvērt administrēšanas lapu. Kad tunelis darbojas, pretstāvieties kārdinājumam atrisināt sasniedzamību, atļaujot visu tuneļa saskarnē. Dodiet administratoriem noteikumu, kas piesaistīts viņu pašu tuneļa adresei, vai atsevišķu tuneli tikai administratoriem, un turiet parastos lietotājus, NAS, kameras un ģimenes klēpjdatorus tālu no pārvaldības porta. Partnerim, kuram nepieciešama failu koplietošana, nevajadzētu būt viena noteikuma attālumā no maršrutētāja pieteikšanās.

Maršrutētāja loma maina atbildi. Maršrutētājs, kas pabeidz tuneli, var likumīgi pieņemt no tā administratorus, savukārt maršrutētājs, kas tuneli izmanto tikai kā izeju internetā, parasti to nedrīkstētu. Abos gadījumos apakštīkla atļauja nav pieteikšanās, tāpēc atstājiet ieslēgtu konta autentifikāciju un transporta drošību.

Kompensējošais solis, ko cilvēki veic pēc bloķēšanas, ir sliktāks: WAN administrēšanas ieslēgšana vai porta pāradresēšana uz tīmekļa saskarni. Tas īsu pārtraukumu pārvērš pastāvīgā apdraudējumā, un pieteikšanās lapa tad kļūst sasniedzama ikvienam interneta skenerim. Pārbaudiet arī atteikto pusi, ne tikai atļauto, lai partneris, kuram nevajadzētu būt administratora piekļuvei, saņemtu taimautu vai atteikumu, nevis pieteikšanās uzvedni.

Pārbaudiet arī ar jaunu savienojumu. Stāvokļa ugunsmūris savā stāvokļu tabulā tur esošās plūsmas, tāpēc jau atvērtā SSH sesija var pārdzīvot izmaiņas, kas bloķē katru jaunu savienojumu. Tā bloķēšana paliek neredzama līdz nākamajai pārstartēšanai vai nākamajai klēpjdatora gulēšanai.

Sagatavojiet atgriešanās ceļu, pirms pieskaraties politikai

Pirms pirmās izmaiņas pierakstiet četras lietas: kā jūs nokļūsiet pie ierīces, ja tunelis mirs, piemēram, virknes konsole, pakalpojumu sniedzēja konsole vai mašīna LAN tīklā; kur tiek eksportēta pašreizējā konfigurācija; kuru vienu noteikumu vai maršrutu jūs mainīsiet; un kā jūs precīzi atgriezīsiet šo vienumu. OpenWrt sysupgrade -b /tmp/backup.tar.gz fiksē konfigurāciju, un izmaiņas paliek gaidīšanā līdz uci commit, kas dod lētu atsaukšanu, ja pamanāt laikus. pfSense uztur konfigurācijas vēsturi, un AutoConfigBackup palīdz tikai tad, ja tas jau bija ieslēgts. Ja maršrutētājs darbojas ar fail-closed noteikumu kopu, pārliecinieties, ka plānotais apkopes ceļš neatrodas tās plūsmas iekšienē, ko bloķē šis noteikums, un atcerieties, ka pārstartēšana atkārtoti piemēro pastāvīgos noteikumus, nevis tos dzēš.

Mainiet vienu robežu katrā mēģinājumā, tad pārbaudiet no jauna savienojuma, nevis no čaulas, ko turat atvērtu. Ja pārbaude neizdodas, atsauciet šo vienu izmaiņu, pirms pieskaraties nākamajam slānim. Tunelis var palikt pacelts visu laiku, bet tā zaļā statusa ikona nav pierādījums, ka jūs joprojām varat iekļūt.

Ātra pārbaude pirms aiziešanas:

• Vai jūs sasniedzat maršrutētāju no avota, kas nav atkarīgs no tikko rediģētā noteikuma?
• Vai tuneļa saskarnes ievades politika atļauj tikai administratora avotu?
• Vai pārvaldības pakalpojums ir piesaistīts adresei, kas pastāv tunelī?
• Vai esat pārbaudījis vienu atteiktu partneri un vienu jaunu sesiju?
• Vai WAN administrēšanas virsma joprojām ir slēgta?