Wêrom't thús-NAT jo VPN-ynterface net beskermet
In thúsrûter stjoert de tunnel troch, mar de host beoardielet it ûntsifere pakket. Lês de listener, it binnenpaad en it ynfierbelied apart.
Laptops efter in thúsrûter sûnder port-oerstjoering akseptearje noch altyd SSH-ferbiningen dy't oer de VPN komme. Dat is gjin tsjinspraak, want twa ferskillende apparaten beoardielje twa ferskillende pakketten. De rûter stjoert it fersifere transport troch, en de host beslút wat te dwaan mei it ûntsifere pakket dat by syn tunnel-ynterface oankomt. Dy twa besluten los faninoar hâlde is de hiele oefening.
De rûter stjoert de tunnel troch, de host beoardielet it pakket
Tekenje it paad fan 'e fiere boarne nei de tsjinst foardat jo nei ien regel sjogge. It bûtenste stik is it VPN-transport, dat troch de rûter en de gateway behannele wurdt. It binnenste stik begjint as it einpunt de tunnellaach strippet en de host in pakket ûntfangt dat oan syn VPN-adres rjochte is.
Foege dy twa stikken byinoar en de rûter krijt kredyt foar in beslút dat de host nimt. In port-oerstjoeringsside of in rûterlog beskriuwt allinnich bûtenste petearen, en gjinien seit hokker ûntsifere ferkear de host akseptearret. De host past syn eigen ynkommend belied ta op it binnenste pakket, krekt as op elk pakket dat op in ynterface oankomt. Yn dat belied wurdt de bleatstellingsfraach echt besljochte.
In wildcard-listener is gjin iepenbiere tsjinst
Op Linux betsjut binen oan INADDR_ANY elk lokaal adres, dus in tsjinst kin antwurdzje op in tunnel-ynterface dy't er nea neamd hat. De IP-socketreferinsje beskriuwt dat binen, en it is de muoite wurdich te lêzen foardat jo konklúzjes út in listenerlist lûke. In wildcard-ynfier is in feit oer de socket, gjin bewearing oer berikberens.
De twa rigels hjirûnder binne deselde tsjinst yn twa ferskillende binings, en it ferskil is it hiele antwurd op 'e fraach oft it ynterface fan belang is. Lês op hokker adres de socket sit foardat al it oare.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))Neam de regeling dy't de poarte berikke koe
Trije regelingen sette in pakket op dat ynterface, en se hawwe ferskillende eigners. De juste neame beslút wa't in belied feroarje moat.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
In browserresultaat dat in iepenbier útgongsadres toant seit neat oer ien fan 'e trije, want it beskriuwt hoe't útgeand ferkear fuortgiet ynstee fan wat yngeand ferkear tastien is. Wurkje efterstfoar fan 'e listener en it boarneadres yn 'e tsjinstlog. As de boarne in oare tunnel-peer is, is it gateway-belied it nijsgjirrige dokumint. As it in oerset adres is, fyn de oersetting foardat jo in regel feroarje.
Behein de tsjinst ta it paad dat jo bedoelden
As SSH allinnich fan in behearpaad nedich is, skriuw dat paad dan del as in boarneberik plus in ynterface. Behein dan de ynkommende regels fan 'e host neffens ynterface, bestimming en boarne ynstee fan neffens netwurknamme, om't in namme dy't privee liket foar elk adres stean kin. Hâld in route yn foar de persoan dy't it folgjende probleem oplosse sil.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter inputIn regel dy't it tunnel-ynterface en it behearberik neamt, seit de bedoeling op ien plak. Fergelykje him mei in regel skreaun foar it Wi-Fi-netwurk, dy't neat oer ûntsifere tunnelferkear seit. As de twa lagen it net iens binne, is it hostbelied dejinge dy't it pakket treft.
Lit oanmeldingen en patches krekt dêr wêr't se binne; in poarte berikke wie nea itselde as tastien wurde om him te brûken. Skriuw de adresfamylje en tiid op foar elke ûnbekende boarne, en ûndersykje foardat jo in funksje of in kwetsberens de skuld jouwe. In regel dy't elke tunnel-peer talit is in oar ûntwerp as ien dy't in behearsubnet talit, en gjin logregel sil sizze hokker bedoeld wie.
Akseptearje de oplossing mei ien sukses en ien wegering
Bewiis beide helten: ien goedkarde ferbining slagget en ien útsletten paad wurdt wegere. De wegering is it helt dat minsken oerslaan, en it is dejinge dy't sjen lit dat de regel wurk docht ynstee fan njonken in tastimmende standert te stean. Test fan 'e útsletten kant ynstee fan deroer te redenearjen.
Werhelje it pear nei in werferbining, want in tunnel dy't weromkomt mei in oare ynterfacenamme kin stil in regel omseilje dy't op 'e âlde beheind is. De grins dy't fan belang is, is dejinge dy't de host tapast op pakketten dy't er wier ûntfangt.