Vai klejojošs VPN klients var mitināt pakalpojumu birojam?

Jūsu biroja portatīvais dators var pieslēgties no mājām un joprojām nodrošināt kaut ko tādu, kas birojam nepieciešams, bet tikai tad, kad sakrīt trīs atsevišķi lēmumi. Tunelis ir transports, iekšējā adrese ir galamērķis, un politika nosaka, kas drīkst pieklauvēt. Ja kādu no tiem uzskata par visu atbildi, rodas pazīstamā sūdzība: resursdators atbild uz ping, bet lietojumprogramma nekad nepievienojas. Lomas nav vienādas, un atšķirība ir tieši tur, kur dzīvo dizaina darbs.

Pieslēgšanās virziens neko nepasaka par pakalpojuma virzienu

Kad klients sāk tuneli, tas atver ceļu, ko pēc tā izveides var izmantot abi virzieni. Vai jauns savienojums drīkst ienākt no centra uz šo klientu, ir vārtejas politikas jautājums, nevis tā īpašība, kurš pieslēdzās. Piemēram, maršrutētā OpenVPN centrā serverim ir vajadzīgs maršruts uz klienta iekšējo adresi un pāradresācija, kas atļauj vienādranga attiecības.

Iedomājieties krājumu sistēmu, kas aptaujā aģentu klejojošos portatīvajos datoros, vai izstrādātāju, kuram nepieciešama testa API no darbstacijas mājās. Abi vēlas, lai sarunu sāktu biroja puse, kas ir pretēji ierastajam klienta-uz-serveri modelim.

Mitinātie attālinātās piekļuves produkti šeit atšķiras, un šī atšķirība nav kļūda. Daži pārvaldīti VPN pakalpojumi apzināti bloķē nepieprasītus savienojumus uz pievienotajiem klientiem, jo to modelis ir klients-uz-resursu, nevis resurss-uz-klientu. Izlasiet produkta dokumentēto arhitektūru, pirms solāt kolēģim, ka viņa portatīvais dators var darboties kā serveris.

Sekojiet atgriešanās ceļam, pirms atverat portu

Ceļam ir trīs daļas: maršruts uz vārtejas, kas norāda uz klienta iekšējo adresi, politika, kas atļauj konkrēto zvanītāju, un klausošs pakalpojums mērķī. Katra daļa neizdodas citādi, tāpēc «VPN ir ieslēgts» gandrīz neko nepasaka.

Labā ziņa ir tā, ka iekšējam ceļam nav vajadzīga porta pāradresācija klienta mājas maršrutētājā. Tieši tāda ir jēga publicēt pakalpojumu tuneļa adresē, nevis mājas WAN adresē, kur pakļautība un NAT noteikumi būtu pilnīgi citādi. Mājas maršrutētājs var arī atteikties hairpinot savienojumu, kas nāk no biroja, tāpēc WAN ceļš neizdodas iemeslu dēļ, kas nav saistīti ar jūsu VPN. Datplūsmas turēšana tuneļa iekšienē vienlaikus izvairās no abām problēmām.

Pārbaudiet arī mērķa pusi. Pakalpojums, kas saistīts tikai ar 127.0.0.1, nevar pieņemt savienojumu, kas ienāk tuneļa saskarnē, lai cik pareizi būtu vārtejas maršruti. Resursdatora ugunsmūra noteikums, kas atļauj portu tikai no vietējā apakštīkla, arī izmetīs biroja datplūsmu, un šis noteikums ir neatkarīgs no VPN politikas virs tā.

Vārdi un adreses ir dizaina lēmumi

Adrese tuneļa iekšienē nav automātiski vārds. Jūsu kontrolēts privāts DNS ieraksts ir skaidrāks par cerību, ka atklāšanas protokols šķērsos tuneli, jo link-local multicast vārdu izšķiršana paliek vietējā segmentā un nekļūst par DNS starp apakštīkliem.

Adreses stabilitāte ir tikpat svarīga. Ja VPN klienti ņem no baseina ar īsiem nomas termiņiem, portatīvā datora iekšējā adrese mainās starp sesijām un katra uz tās balstītā grāmatzīme, ugunsmūra tvērums un uzraudzības pārbaude klusi salūzt. Izmantojiet rezervāciju vai dokumentētu dinamiskās atjaunināšanas ceļu.

Saskaņojiet vārdu ar to, kam pieder VPN identitāte, lai ieraksts, adreses piešķiršana un piekļuves politika mainītos kopā, nevis trīs atsevišķos pieteikumos.

Pārbaudiet pakalpojumu, nevis dalību

No mērķa pārbaudiet, kas klausās un kurā adresē, pēc tam pārbaudiet vārtejas skatījumu uz atgriešanās ceļu:

$ 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

Tagad pārbaudiet no biroja puses ar īstu pieprasījumu, nevis atbalsi. Veiksmīgs curl pret pakalpojumu pierāda maršrutu, politiku un klausītāju uzreiz, savukārt veiksmīgs ping pierāda tikai to, ka ICMP ir atļauts. Ja pieprasījums neizdodas, ejiet atpakaļ cauri trim daļām, nevis paplašiniet ugunsmūri un ceriet.

Pieejamība pieder pie tās pašas sarunas. Portatīvais dators guļ, klejo starp tīkliem un atvienojas dienas beigās. Pakalpojums, kam jāatbild jebkurā stundā, pieder pastāvīgi ieslēgtam resursdatoram, savukārt labāko pūļu pakalpojums var palikt klientā ar šo ierobežojumu pierakstītu.

Publicējiet resursu apzināti, ar vārdu, atļauto zvanītāju sarakstu un īpašnieku, un attālinātā ierīce kļūst par atbalstītu pakalpojumu, nevis nejaušu serveri.