Hur man avgör om en brandväggs- eller NAT-regel blockerar en inkommande anslutning till en hemserver

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Testa från utanför hemnätverket och följ anslutningen inåt tills paketet försvinner.

En inkommande anslutning till en självhostad app kan misslyckas eftersom tjänsten inte lyssnar, värdens brandvägg avvisar den, routern vidarebefordrar fel port eller adress, WAN är bakom CGNAT eller dubbel NAT, eller svaret lämnar via fel gateway. Den säkraste diagnosen håller den offentliga exponeringen smal, verifierar en TCP- eller UDP-tjänst i taget och använder lyssnarutdata, routerräknare, brandväggsloggar och paketfångster för att identifiera det första saknade steget.

Bekräfta att tjänsten lyssnar på förväntat gränssnitt

Börja på hemservern själv. Verifiera att processen körs, att den avsedda TCP- eller UDP-porten är öppen och att lyssnaren är bunden till LAN-adressen eller alla nödvändiga gränssnitt snarare än endast 127.0.0.1 eller ett nätverk som endast används av en container.

Baeldungs guide för porttestning förklarar att en socket i LISTEN-läge är redo att acceptera anslutningar, men bind-adressen avgör fortfarande vilka gränssnitt som kan nå den.

Testa tjänsten från en annan LAN-enhet med serverns privata IP och exakt port. Om det misslyckas, stanna vid servern eller den lokala VLAN-vägen; en NAT-regel kan inte vidarebefordra trafik framgångsrikt till en tjänst som inte är nåbar från routerns sida av LAN.

Använd en extern klient istället för att testa från samma LAN

Koppla bort en telefon från Wi-Fi eller använd ett system på en annan internetanslutning. Testa den offentliga IP-adressen eller domänen, extern port och korrekt protokoll medan mål-tjänsten aktivt lyssnar.

Lifewires guide för portvidarebefordran noterar att routerregeln och datorns brandvägg båda måste tillåta anslutningen, och rekommenderar att kontrollera öppna portar från utanför nätverket snarare än att förlita sig på en lokal webbläsare som kan stöta på NAT-loopback-beteende.

Anteckna om klienten ser en timeout, omedelbar avvisning, TLS-fel eller applikationssvar. En avvisning betyder ofta att en nåbar värd inte har någon accepterande tjänst på den vägen; en tyst timeout är mer förenlig med filtrering, saknad vidarebefordran, upstream NAT eller en otillgänglig destination.

Jämför routerns WAN-adress med den offentliga adressen

Läs WAN-adressen som visas av hemroutern och jämför den med den offentliga adress som rapporteras av en extern tjänst. De bör matcha för vanlig IPv4-portvidarebefordran om inte en annan upstream-router utför den första NAT.

Om routerns WAN-adress är privat, delad eller skiljer sig från den offentliga adressen kan vidarebefordringsregeln ligga bakom dubbel NAT eller carrier-grade NAT. I det fallet når paketet aldrig routerregeln oavsett hur ofta den lokala brandväggen ändras.

Vidarebefordra samma port på den upstream-gateway du kontrollerar, begär en användbar offentlig adress från ISP:n eller välj en VPN, utgående tunnel eller relä när inkommande vidarebefordran inte är tillgänglig. Försvaga inte serverns brandvägg för att kompensera för ett paket som aldrig når hemroutern.

Övervaka NAT-räknare och brandväggsloggar under ett test

Rensa eller spela in relevanta routerräknare, aktivera loggning på den smala testregeln och skicka sedan ett externt anslutningsförsök. Den viktiga frågan är om WAN-paketet matchar NAT-regeln och om det översatta paketet matchar tillåt-regeln.

En MikroTik-felsökningsfall fångar det vanliga kravet på både en NAT-regel och brandväggsregel. Översättning ändrar destinationen; det garanterar inte att brandväggen tillåter den vidarebefordrade trafiken.

Om ingen räknare ändras, kontrollera den offentliga adressen, extern port, gränssnitt och upstream NAT. Om NAT räknas upp men tillåt-regeln inte gör det, kontrollera regelordning och översatt destination. Om båda räknas upp, fånga på servern för att se om paketet anländer.

Verifiera det interna målet, protokollet och returvägen

Bekräfta att NAT-regeln pekar på serverns aktuella reserverade adress och rätt interna port. Kontrollera om applikationen förväntar sig TCP, UDP eller båda, eftersom ett lyckat TCP-test inte säger något om en UDP-endast tjänst.

PortForwards felsökningsråd lyfter fram två vanliga misstag: vidarebefordran till fel dator och att lämna en programvarubrandvägg som blockerar appen efter att routerregeln skapats.

När paketet når servern men inget svar returneras, kontrollera serverns gateway, policy-routing, containernätverk och asymmetrisk multi-NIC-väg. Tjänsten måste skicka sitt svar tillbaka via en rutt som bevarar brandväggs- och NAT-status som skapats av det inkommande paketet.

Ta bort testregeln när den inte behöver vara offentlig

När det felande lagret identifierats, gör den minsta korrigeringen och upprepa samma test utifrån och in. Öppna inte ett portintervall eller inaktivera hela brandväggen bara för att se om något förändras.

ZimaSpace-guiden för att kontrollera exponering av hemserver ger nästa säkerhetskontroll efter att en vidarebefordringsregel börjar fungera.

Behåll en offentlig regel endast när tjänsten är avsiktligt internetexponerad, autentiserad, patchad, loggad och isolerad från administrationsgränssnitt. För privata instrumentpaneler, SSH, SMB och personliga filer är en VPN eller autentiserad tunnel vanligtvis en tydligare gräns än en permanent vidarebefordrad port.

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.