Wêrom't it behear fan 'e router ophâldt te antwurdzjen nei in VPN-wiziging

Jo hawwe in rûte of in firewallregel feroare om in tunnel op 'e router te testen, en no antwurdet de behearspagina net mear fan 'e laptop ôf dy't tsien minuten lyn noch goed wurke. De refleks is om de VPN de skuld te jaan. Meastentiids is de tunnel sûn en is ien fan trije oare dingen brutsen: gjin rûte werom nei it eigen adres fan 'e router, in ynfierbelied dat it fersyk weilittet, of in websjinst dy't net harket op it adres dat jo oproppe. Alle trije sjogge der itselde út yn 'e browser, dêrom starte minsken in oere lang de tunnel op 'e nij en leare se neat.

Hjir is de myte dy't it earst wurdich is om dea te meitsjen: in wurkjende tunnel is gjin wei werom nei binnen. It is in nije netwurkferbining mei syn eigen fertrouwensfragen, en it kin jo âlde behearpaad stil fuorthelje wylst it in nije iepenet dy't nimmen neisjoen hat.

De tunnel wie nea it behearpaad

Trochstjoeren en ynfier binne ferskillende taken. "Kin in klant it NAS berikke fia de tunnel?" is in trochstjoerfrage oer pakketten dy't troch de router geane. "Kin ik de SSH-poarte fan 'e router iepenje?" is in ynfierfrage oer pakketten dy't oan 'e router sels rjochte binne. In regel dy't skreaun is foar trochstjoerd ferkear docht neat foar de twadde, en dat is de meast foarkommende reden wêrom't in tunnel dy't ferkear perfekt ferfiert dochs jo behearsesje wegeret.

De omkearde flater is in ynterfacenamme fertrouwe. In tunnel is fersifere nei de partner, net nei elke sjinst der efter, en it wurd VPN yn in ynterfacelabel seit neat oer hokker boarnen oanmelde meie.

Laach ien: is der in rûte nei it eigen adres fan 'e router?

Begjin op 'e klant en freegje de kernel wêr't it pakket hinne sil. Op Linux prints ip route get 10.6.0.1 de keazen rûte, de útgongsynterface en it boarneadres. As it de standertrûte nei jo provider meldt, komt it pakket nea yn 'e tunnel, en gjin inkelde regel op 'e router kin dat rêde.

De tunnelkant hat syn eigen ferzje fan 'e fraach. WireGuard behannelet AllowedIPs as in kryptokaai-routingtabel: oan elk ein ferklearret it hokker boarneadressen in partner brûke mei en hokker bestimmingen nei dy partner stjoerd wurde. As de klantynfier it tunneladres fan 'e router net befettet, hat de klant gjin rûte derhinne. As de serverynfier foar dy klant it tunneladres fan 'e klant net dekt, smyt de server it pakket fuort foardat in inkelde firewallregel rieplachte wurdt.

Befêstigje it krekte adres dat jo ferwachtsje te berikken foardat jo it belied ûndersykje. In ferâldere DNS-record of in cachet buorrenrecord fan foar de wiziging stjoert jo nei in adres dat de router nea hân hat.

Laach twa: it ynfierbelied, net it trochstjoerbelied

Firewalls beoardielje regels op 'e ynterface wêr't it pakket oankomt. Op pfSense en OPNsense beslute it ynterfacelade en de regelisfoarming oft ferkear nei de eigen sjinsten fan 'e firewall tastien is; in regel dy't LAN-klanten nei it ynternet lit, is gjin regel dy't in tunnelpartner de web-GUI iepenje lit. Op OpenWrt mei firewall4 hat elke sône in ynfierbelied, option input 'ACCEPT' of 'REJECT', en in tunnelinterface yn in sône mei ynfier REJECT sil behearferbiningen wegerje wylst it ferkear noch trochstjoert as trochstjoeren tastien is.

Skeakelje de anty-lockout-regel net út om it nije paad wurkje te litten. Dy regel hâldt it LAN-behearadres derfan ôf om troch in minne regel bûtensletten te wurden; it beskermet it LAN-subnet, net it tunnelsubnet dat jo krekt makke hawwe. Foegje ien smelle regel ta foar de boarne fan 'e administrator en lit it feilichheidsnet gewurde. De pfSense dokumintaasje oer beheartagong ferklearret wêr't dy kontrôles sitte.

# 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

Laach trije: harket der eat op dat adres?

In tsjinst kin rinne en dochs net berikber wêze om't er oan ien adres bûn is. De uhttpd fan OpenWrt hâldt eksplisite harkynfier yn /etc/config/uhttpd, bygelyks list listen_http '0.0.0.0:80'; in bou dy't allinnich oan it LAN-adres bûn is, akseptearret neat op it tunneladres, en produkten dy't in harkynterface-ynstelling sjen litte, gedrage har itselde. De harkopdrachten hjirboppe antwurdzje dat direkt.

Skied dan wegering fan stilte. nc -vz 10.6.0.1 443 dy't in wegere ferbining weromjout, betsjut dat it pakket de router berikt hat en dat eat it wegere hat, itsij in sletten poarte itsij in eksplisite wegeringsregel. In hingjen oant de tiidferrinnen betsjut dat it pakket weilitten is of nea rûte wurden is. Dat ferskil fertelt jo hokker laach jo folgjende ynspektearje moatte, en it kostet fiif sekonden.

In VPN-ynterface is in grins, gjin werstelpaad

Fersifering beskermet de tried; it seit neat oer wa't de behearspagina iepenje mei. Sadree't de tunnel wurket, wjersteanje de oanstriid om berikberens op te lossen troch alles op 'e tunnelinterface ta te litten. Jou administrators in regel keppele oan har eigen tunneladres of in aparte tunnel allinnich foar administrators, en hâld gewoane brûkers, it NAS, de kamera's en de laptops fan 'e famylje fuort fan 'e behearpoarte. In partner dy't bestânsdieling nedich hat, soe net ien regel fan 'e oanmelding fan 'e router ôf wêze moatte.

De rol fan 'e router feroaret it antwurd. In router dy't de tunnel beëiniget, mei administratoren dêrút akseptearje, wylst in router dy't de tunnel allinnich as ynternetútgong brûkt dat meastentiids net heart te dwaan. Yn beide gefallen is de subnetfergunning net de oanmelding, dus hâld akkountautentikaasje en ferfiersbefeiliging oan.

De kompensearjende beweging dy't minsken nei in lockout meitsje, is slimmer: WAN-behear ynskeakelje of in poarte nei de web-GUI trochstjoere. Dat makket fan in koarte steuring in permaninte bleatstelling, en de oanmeldside is dan berikber foar elke skanner op it ynternet. Test ek de wegere kant, net allinnich de tastiene, sadat in partner dy't gjin beheartagong hawwe moat, in tiidferrinnen of wegering krijt yn plak fan in oanmeldingsprompt.

Test ek mei in frisse ferbining. In stateful firewall hâldt besteande streamen yn syn steattabel, dus de SSH-sesje dy't jo al iepen hawwe, kin in wiziging oerlibje dy't elke nije ferbining blokkearret. Sa bliuwt in lockout ûnsichtber oant de folgjende werstart of de folgjende sliep fan 'e laptop.

Meitsje de wei werom klear foardat jo belied oanreitsje

Skriuw fjouwer dingen op foar de earste wiziging: hoe't jo it apparaat berikke as de tunnel deaget, lykas in seriale console, in providerconsole of in masine op it LAN; wêr't de hjoeddeiske konfiguraasje eksportearre wurdt; hokker inkelde regel of rûte jo op it punt steane te wizigjen; en hoe't jo krekt dat item weromdraaie. Op OpenWrt fangt sysupgrade -b /tmp/backup.tar.gz de konfiguraasje, en bewurkingen bliuwe yn wacht oant uci commit, wat jo in goedkeape ûngedien meitsjen jout as jo it op tiid merke. pfSense hâldt in konfiguraasjeskiednis by, en AutoConfigBackup helpt allinnich as it al oan stie. As de router in fail-closed regelset draait, befêstigje dan dat it ûnderhâldspaad dat jo pland hawwe net yn it ferkear sit dat dy regel blokkearret, en betink dat in werstart persistinte regels op 'e nij tapast ynstee fan se te wiskjen.

Feroarje ien grins per besykjen, test dan fan in nije ferbining ôf ynstee fan 'e shell dy't jo iepen hâlde. As de test mislearret, draai dy iene wiziging werom foardat jo de folgjende laach oanreitsje. De tunnel kin de hiele tiid omheech bliuwe, mar syn griene statusikoan is gjin bewiis dat jo der noch yn kinne.

Snelle kontrôle foardat jo fuortgeane:

• Kinne jo de router berikke fan in boarne dy't net ôfhinget fan 'e regel dy't jo krekt bewurke hawwe?
• Lit it ynfierbelied op 'e tunnelinterface allinnich de boarne fan 'e administrator ta?
• Is de beheartsjinst bûn oan in adres dat op 'e tunnel bestiet?
• Hawwe jo ien wegere partner en ien frisse sesje test?
• Is it WAN-behearoerflak noch hieltyd ticht?