Zašto kućni NAT ne štiti vaše VPN sučelje
Kućni usmjerivač prosljeđuje tunel, ali host procjenjuje dešifrirani paket. Čitajte osluškivač, unutrašnju putanju i ulaznu politiku odvojeno.
Prijenosna računala iza kućnog usmjerivača bez prosljeđivanja portova i dalje prihvataju SSH veze koje dolaze preko VPN-a. To nije proturječnost, jer dva različita uređaja procjenjuju dva različita paketa. Usmjerivač prosljeđuje šifrirani promet, a host odlučuje što će učiniti s dešifriranim paketom koji stigne na njegovo tunelsko sučelje. Držati te dvije odluke odvojenima cijela je vježba.
Usmjerivač prosljeđuje tunel, host procjenjuje paket
Skicirajte putanju od udaljenog izvora do usluge prije nego što pogledate i jedno pravilo. Vanjski dio je VPN promet, kojim upravljaju usmjerivač i gateway. Unutrašnji dio počinje kada krajnja točka skine sloj tunela i host primi paket adresiran na njegovu VPN adresu.
Spojite ta dva dijela i usmjerivač dobiva zaslugu za odluku koju donosi host. Stranica za prosljeđivanje portova ili zapis usmjerivača opisuje samo vanjske razgovore i nijedno ne kaže koji će dešifrirani promet host prihvatiti. Host primjenjuje vlastitu ulaznu politiku na unutrašnji paket, isto kao na svaki paket koji stigne na sučelje. U toj politici pitanje izloženosti doista se rješava.
Zvjezdani osluškivač nije javna usluga
Na Linuxu vezanje na INADDR_ANY znači svaku lokalnu adresu, pa usluga može odgovarati na tunelskom sučelju koje nikada nije imenovala. Referenca IP socketa opisuje to vezanje i vrijedi je pročitati prije zaključaka iz popisa osluškivača. Zvjezdani unos činjenica je o socketu, a ne tvrdnja o dostupnosti.
Dva retka ispod ista su usluga u dva različita vezanja, a razlika je cijeli odgovor na pitanje je li sučelje važno. Pročitajte na kojoj adresi socket sjedi prije svega ostalog.
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))
Imenujte raspored koji bi mogao dosegnuti port
Tri rasporeda stavljaju paket na to sučelje i imaju različite vlasnike. Imenovanje pravog odlučuje tko mora promijeniti politiku.
| 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 |
Rezultat preglednika koji prikazuje javnu izlaznu adresu ne govori ništa ni o jednom od tri, jer opisuje kako izlazni promet odlazi, a ne što je ulaznom prometu dopušteno. Radite unatrag od osluškivača i izvorne adrese u zapisu usluge. Ako je izvor drugi tunelski peer, politika gatewaya je zanimljiv dokument. Ako je to prevedena adresa, pronađite prijevod prije nego promijenite pravilo.
Ograničite uslugu na putanju koju ste namjeravali
Ako je SSH potreban samo s upravljačke putanje, zapišite tu putanju kao raspon izvora plus sučelje. Zatim ograničite ulazna pravila hosta prema sučelju, odredištu i izvoru, a ne prema nazivu mreže, jer naziv koji izgleda privatno može značiti bilo koju adresu. Zadržite rutu za osobu koja će riješiti sljedeći problem.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input
Pravilo koje imenuje tunelsko sučelje i upravljački raspon izražava namjeru na jednom mjestu. Usporedite ga s pravilom napisanim za Wi-Fi mrežu, koje ne govori ništa o dešifriranom tunelskom prometu. Kada se dva sloja ne slažu, politika hosta je ona koju paket susreće.
Ostavite prijave i zakrpe točno gdje jesu; dosegnuti port nikada nije bilo isto što i smjeti ga koristiti. Zabilježite obitelj adresa i vrijeme za svaki nepoznati izvor i istražite prije nego okrivite značajku ili ranjivost. Pravilo koje propušta svaki tunelski peer drugi je dizajn od onoga koje propušta upravljačku podmrežu i nijedan zapis neće reći što je bilo namjeravano.
Prihvatite popravak s jednim uspjehom i jednim odbijanjem
Dokažite obje polovice: jedna odobrena veza uspijeva, a jedna isključena putanja biva odbijena. Odbijanje je polovica koju ljudi preskaču i ona koja pokazuje da pravilo radi, a ne da stoji uz dopuštajući zadanu vrijednost. Testirajte s isključene strane umjesto da o tome razmišljate.
Ponovite par nakon ponovnog spajanja, jer tunel koji se vrati s drugim imenom sučelja može tiho zaobići pravilo vezano uz staro. Granica koja je važna jest ona koju host primjenjuje na pakete koje doista prima.