Može li roaming VPN klijent hostati uslugu za ured?

Vaš uredski prijenosnik može se povezati od kuće i ipak pružati nešto što uredu treba, ali samo kad se poklope tri odvojene odluke. Tunel je prijevoz, unutarnja adresa je odredište, a politika odlučuje kome je dopušteno pokucati. Ako bilo koju od njih tretirate kao cijeli odgovor, dobivate poznatu žalbu: host odgovara na pingove, ali aplikacija se nikad ne poveže. Uloge nisu iste, a razlika je upravo tamo gdje živi dizajnerski rad.

Smjer povezivanja ne govori ništa o smjeru usluge

Kad klijent pokrene tunel, otvara put koji oba smjera mogu koristiti nakon što postoji. Smije li nova veza ući od čvorišta prema tom klijentu pitanje je gateway politike, a ne svojstvo onoga tko se povezao. Na rutiranom OpenVPN čvorištu, primjerice, poslužitelju treba ruta do unutarnje adrese klijenta i prosljeđivanje koje dopušta peer odnos.

Zamislite inventurni sustav koji ispituje agenta na roaming prijenosnicima ili programera kojem treba testni API s radne stanice kod kuće. Oboje žele da uredska strana započne razgovor, što je obrnuto od uobičajenog obrasca klijent-prema-poslužitelju.

Hostani proizvodi za daljinski pristup razlikuju se ovdje i ta razlika nije greška. Neki upravljani VPN-ovi namjerno blokiraju neželjene veze prema povezanim klijentima jer je njihov model klijent-prema-resursu, a ne resurs-prema-klijentu. Pročitajte dokumentiranu arhitekturu proizvoda prije nego kolegi obećate da njegov prijenosnik može djelovati kao poslužitelj.

Pratite povratni put prije nego otvorite port

Put ima tri dijela: rutu na gatewayu koja pokazuje na unutarnju adresu klijenta, politiku koja dopušta konkretnog pozivatelja i uslugu koja sluša na cilju. Svaki dio zataji drugačije, zato „VPN radi“ ne govori gotovo ništa.

Dobra je vijest da unutarnji put ne treba prosljeđivanje porta na klijentovu kućnom routeru. Upravo je to smisao objavljivanja usluge na adresi tunela umjesto na kućnoj WAN adresi, gdje bi izloženost i NAT pravila bila posve drugačija. Kućni router može i odbiti hairpin veze koja dolazi iz ureda, pa WAN ruta zataji iz razloga nepovezanih s vašim VPN-om. Držanje prometa unutar tunela izbjegava oba problema odjednom.

Provjerite i stranu cilja. Usluga vezana samo uz 127.0.0.1 ne može prihvatiti vezu koja dolazi na sučelje tunela, koliko god gateway rute bile ispravne. Pravilo host firewall-a koje dopušta port samo s lokalne podmreže također će odbaciti uredski promet, a to je pravilo neovisno o VPN politici iznad njega.

Imena i adrese su dizajnerske odluke

Adresa unutar tunela nije automatski ime. Privatni DNS zapis koji kontrolirate jasniji je od nade da će protokol otkrivanja prijeći tunel, jer link-local multicast razrješavanje imena ostaje na lokalnom segmentu i ne postaje DNS između podmreža.

Stabilnost adrese jednako je važna. Ako VPN klijenti dobivaju adrese iz bazena s kratkim zakupom, unutarnja adresa prijenosnika mijenja se između sesija i svaka oznaka, firewall opseg i provjera nadzora izgrađena na njoj tiho se lomi. Koristite rezervaciju ili dokumentiran put dinamičkog ažuriranja.

Uskladite ime s onim tko posjeduje VPN identitet, kako bi se zapis, dodjela adrese i politika pristupa mijenjali zajedno, a ne u tri odvojena zahtjeva.

Testirajte uslugu, a ne članstvo

S cilja potvrdite što sluša i na kojoj adresi, zatim potvrdite kako gateway vidi povratni put:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Sada testirajte s uredske strane stvarnim zahtjevom, a ne odjekom. Uspješan curl prema usluzi dokazuje rutu, politiku i slušatelja odjednom, dok uspješan ping dokazuje samo da je ICMP dopušten. Ako zahtjev ne uspije, idite unatrag kroz tri dijela umjesto da širite firewall i nadate se.

Dostupnost pripada istom razgovoru. Prijenosnik spava, roaming između mreža i isključuje se na kraju dana. Usluga koja mora odgovoriti u svako doba pripada stalno uključenom hostu, dok usluga po načelu najboljeg truda može ostati na klijentu uz zapisano ograničenje.

Objavite resurs namjerno, s imenom, popisom dopuštenih pozivatelja i vlasnikom, i udaljeni uređaj postaje podržana usluga, a ne slučajni poslužitelj.