Čak i prijenosno računalo iza NAT-a davatelja usluge može poslužiti kolegu, sve dok VPN poslužitelj djeluje kao mjesto susreta. Dva mehanizma vode tamo: klijent se spaja prema van i traži od poslužitelja da drži port za slušanje, ili poslužitelj objavi port i prevede ga u tunel. Oba rješavaju isti problem dosegljivosti i ponašaju se različito pod kvarom, nadzorom i zapisivanjem. Tri uvjeta odlučuju koje od njih pripada vašem postavu.

Dva oblika, jedno mjesto susreta

U prvom obliku klijent otvara SSH sesiju prema van i traži od poslužitelja da sluša na odabranom portu, prosljeđujući svaku vezu natrag kroz tu sesiju. Na poslužitelju se ništa ne prosljeđuje i ne događa se nikakvo prevođenje paketa, pa su jedini uvjeti SSH račun, dopušteno prosljeđivanje i pravilo vatrozida za port. Usluga ostaje vezana na loopback na klijentu, što je obično ono što želite.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

U drugom obliku poslužitelj posjeduje javni port i prepisuje svaku vezu prema adresi klijentskog tunela. To zahtijeva uključeno IP prosljeđivanje, prevođenje odredišta na ulazu i prevođenje izvora na izlazu, i nastavlja raditi kad nema SSH sesije. Port pripada poslužitelju, a ne sesiji, i to je svojstvo koje odlučuje u većini stvarnih slučajeva.

Nijedan oblik nije sigurniji sam po sebi. Oba na kraju izlažu jedan port usluge svakome tko može dosegnuti javnu adresu poslužitelja, i oba i dalje ovise o vlastitoj autentikaciji usluge.

Uvjet prvi: mora li port nadživjeti sesiju

Obrnuto prosljeđivanje živi točno onoliko koliko i SSH sesija koja ga je stvorila. Kad veza padne, slušatelj nestaje i kolega vidi odbijenu vezu umjesto sporog puta. Nadzor naredbe pomoću systemd jedinice i politike ponovnog pokretanja to rješava, a ExitOnForwardFailure=yes čini neuspjelo vezanje odmah vidljivim umjesto da ostavi sesiju koja radi bez prosljeđivanja.

Prevedeni port preživljava ponovna pokretanja ako su pravila trajno spremljena, ali ovisi o tome da klijent zadrži istu adresu tunela. Dinamički bazen koji prijenosnom računalu nakon ponovnog spajanja dodijeli drugu adresu tiho usmjerava pravilo u prazno. Prvo rezervirajte adresu tunela, zatim napišite pravilo i tretirajte to dvoje kao jednu promjenu.

Ako usluga mora odgovarati u tri sata ujutro bez ikoga da gleda, oblik s portom koji objavljuje poslužitelj ima manje pokretnih dijelova, jer jedini proces koji mora ostati pokrenut jest sam tunel.

Uvjet drugi: kome pripadaju vatrozid i zapisi

Obrnuti oblik drži svu politiku na dva mjesta. sshd odlučuje jesu li udaljena prosljeđivanja uopće dopuštena kroz AllowTcpForwarding, a GatewayPorts odlučuje hoće li se slušatelj vezati na loopback ili na svaku adresu. Uz zadanu vrijednost no kolega izvan poslužitelja ne može dosegnuti port iako je prosljeđivanje uspjelo, i to izgleda kao pokvaren tunel dok je zapravo adresa vezanja.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Prevedeni oblik zahtijeva uključeno prosljeđivanje i dva pravila, a drugo pravilo je mjesto gdje većina recepata pogriješi. Ograničavanje prevođenja izvora na conntrack stanje DNAT znači da se prepisuju samo veze koje je stvorilo pravilo odredišta, umjesto svakog paketa koji poslužitelj pošalje u tunel.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

To prepisivanje ujedno uništava atribuciju. Nakon njega klijent vidi svakog pozivatelja kao adresu poslužiteljskog tunela, što svako ograničenje brzine po adresi sažima u jednu kantu i skriva tko je što poslao. Ako je atribucija važna, prekinite vezu na poslužitelju ili tamo zadržite odluku o dopuštenju i prenesite identitet u zaglavlju kojemu usluga vjeruje. Odabir između tih dvaju popravaka ovisi o tome čita li usluga uopće proxy zaglavlje.

Uvjet treći: jedan port ili mnogo njih, i kome pripada ime

Jedna usluga na jednom portu slučaj je u kojem obrnuto prosljeđivanje pobjeđuje po trudu. Trebate jednu naredbu, jedan račun i jedno pravilo vatrozida, a čišćenje je prekid sesije. Više usluga na istoj javnoj adresi gura vas prema obliku s portom koji objavljuje poslužitelj, jer svako obrnuto prosljeđivanje treba svoj port poslužitelja i skup raste sa svakom uslugom.

Imena to dodatno kompliciraju. Obrnuto prosljeđivanje može stajati iza TCP proxyja koji usmjerava prema SNI-ju, dok je prevedeni port obično jedan port po usluzi. Ako usluga sama završava TLS i treba izvorno ime hosta, pristup s proxyjem ga čuva, a pristup s DNAT-om čuva ga samo ako usluga prihvaća to ime na tom portu.

Zapišite koji je od tri uvjeta odlučio oblik. Inače će sljedeća osoba koja doda drugu uslugu ponovno otvoriti istu usporedbu s manje konteksta.

Odlučite, zatim testirajte izvana

Testirajte put iz mreže koja nema rutu do prijenosnog računala i promatrajte brojače na poslužitelju dok zahtjev traje. Testiranje s poslužitelja prema njegovoj vlastitoj javnoj adresi ovdje ništa ne dokazuje, jer se paket stvara lokalno i nikada ne dolazi do ulazne kuke za prevođenje, pa test može proći dok je stvarni put pokvaren.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Brojači koji stoje znače da paket nikada nije stigao do pravila, što upućuje na davatelja usluge ili vatrozid hosta. Brojači koji se pomiču dok usluga odbija upućuju na klijentov vlastiti vatrozid ili adresu na kojoj usluga sluša. Tunel koji prenosi paket ali ništa ne vraća problem je rute ili povratnog puta, i nijedan od tih triju ishoda ne treba otklanjati uređivanjem klijentskog adaptera. Zapišite koji se brojač pomaknuo prije nego što išta promijenite, jer sljedeći test treba tu osnovicu.

Kad oblik proradi, zapišite port, vlasnika i način nadzora uz konfiguraciju tunela. Popravak dosegljivosti koji postoji samo u nečijoj povijesti ljuske udaljen je jedno ponovno pokretanje od ponovljenog incidenta.

Povezani članci