Ali lahko gostujoči odjemalec VPN gosti storitev za pisarno?

Gostujoči odjemalec lahko streže pisarniškim sistemom le, ko prehod usmerja proti njemu, ko politika gostitelja to dovoljuje in ko naprava ostane dosegljiva dovolj dolgo.

Vaš pisarniški prenosnik se lahko prijavi od doma in še vedno nudi nekaj, kar pisarna potrebuje, a le ko se ujemajo tri ločene odločitve. Tunel je prenos, notranji naslov je cilj, politika pa odloča, kdo sme potrkati. Če katero od tega obravnavate kot celoten odgovor, dobite znano pritožbo: gostitelj odgovarja na ping, aplikacija pa se nikoli ne poveže. Vloge niso enake in razlika je natanko tam, kjer živi oblikovalsko delo.

Smer prijave ne pove ničesar o smeri storitve

Ko odjemalec začne tunel, odpre pot, ki jo po nastanku lahko uporabljata obe smeri. Ali sme nova povezava vstopiti iz vozlišča proti temu odjemalcu, je vprašanje politike prehoda, ne lastnost tistega, ki se je prijavil. Na usmerjenem vozlišču OpenVPN strežnik na primer potrebuje pot do notranjega naslova odjemalca in posredovanje, ki dovoljuje odnos enakovrednih vozlišč.

Predstavljajte si sistem zalog, ki anketira agenta na gostujočih prenosnikih, ali razvijalca, ki potrebuje preskusni API z delovne postaje doma. Oba želita, da pogovor začne pisarniška stran, kar je nasprotje običajnega vzorca odjemalec-proti-strežniku.

Gostovani izdelki za oddaljeni dostop se tu razlikujejo in ta razlika ni napaka. Nekateri upravljani VPN namerno blokirajo neželene povezave proti povezanim odjemalcem, ker je njihov model odjemalec-proti-virom, ne vir-proti-odjemalcu. Preberite dokumentirano arhitekturo izdelka, preden sodelavcu obljubite, da lahko njegov prenosnik deluje kot strežnik.

Sledite povratni poti, preden odprete vrata

Pot ima tri dele: pot na prehodu, ki kaže na notranji naslov odjemalca, politiko, ki dovoljuje konkretnega klicatelja, in storitev, ki posluša na cilju. Vsak del se pokvari drugače, zato „VPN je vklopljen“ ne pove skoraj ničesar.

Dobra novica je, da notranja pot ne potrebuje posredovanja vrat na domačem usmerjevalniku odjemalca. To je smisel objave storitve na naslovu tunela namesto na domačem naslovu WAN, kjer bi bila izpostavljenost in pravila NAT povsem drugačna. Domači usmerjevalnik lahko tudi zavrne hairpin povezave, ki prihaja iz pisarne, zato pot WAN odpove iz razlogov, nepovezanih z vašim VPN. Zadrževanje prometa znotraj tunela se izogne obema težavama hkrati.

Preverite tudi ciljno stran. Storitev, vezana samo na 127.0.0.1, ne more sprejeti povezave, ki prispe na vmesnik tunela, ne glede na to, kako pravilne so poti prehoda. Pravilo požarnega zidu gostitelja, ki dovoljuje vrata le iz lokalnega podomrežja, bo prav tako zavrglo pisarniški promet, in to pravilo je neodvisno od politike VPN nad njim.

Imena in naslovi so oblikovalske odločitve

Naslov znotraj tunela ni samodejno ime. Zasebni zapis DNS, ki ga nadzorujete, je jasnejši od upanja, da bo protokol za odkrivanje prešel tunel, ker razreševanje imen z lokalnim multicastom ostane v lokalnem segmentu in ne postane DNS med podomrežji.

Stabilnost naslova je enako pomembna. Če si odjemalci VPN izposojajo iz bazena s kratkimi najemi, se notranji naslov prenosnika med sejami spremeni in vsak zaznamek, obseg požarnega zidu in preverjanje nadzora, zgrajeni na njem, se tiho zlomijo. Uporabite rezervacijo ali dokumentirano pot dinamičnega posodabljanja.

Dogovorite ime s tistim, ki ima identiteto VPN, da se zapis, dodelitev naslova in politika dostopa spremenijo skupaj, ne v treh ločenih zahtevkih.

Preizkusite storitev, ne članstva

S cilja potrdite, kaj posluša in na katerem naslovu, nato potrdite pogled prehoda na povratno pot:

$ 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

Zdaj preskusite s pisarniške strani z resnično zahtevo namesto z odmevom. Uspešen curl proti storitvi dokaže pot, politiko in poslušalca hkrati, medtem ko uspešen ping dokaže le, da je ICMP dovoljen. Če zahteva ne uspe, se vrnite po treh delih, namesto da bi širili požarni zid in upali.

Razpoložljivost spada v isti pogovor. Prenosnik spi, gostuje med omrežji in se ob koncu dneva odklopi. Storitev, ki mora odgovoriti ob kateri koli uri, spada na vedno vključenega gostitelja, medtem ko lahko storitev po najboljših močeh ostane na odjemalcu s to omejitvijo zapisano.

Vir objavite namerno, z imenom, seznamom dovoljenih klicateljev in lastnikom, in oddaljena naprava postane podprta storitev, ne naključni strežnik.

Sorodni članki