VPN sur la enkursigilo aŭ pordoredirekto: kiu venkas?

La enkursigilo mem finas la VPN-on, kaj malnova edirekta regulo ankoraŭ sendas la saman UDP-pordon al maŝino en la loka reto. Nur unu el tiuj povas esti la vera finpunkto, kaj la kerno ne arbitras. Celdirekta tradukado reverkas la paketon antaŭ ol konsulti la lokan servon, do la VPN-procezo atendas trafikon jam senditan aliloken. La tasko estas decidi, kiu posedas la pordon, kaj poste akordigi la regulojn.

Unu pordo, du pretendataj posedantoj

VPN-servilo kuranta ene de la enkursigilo bezonas envenan permeson, kiu kondukas al ĝia propra soketo. Cel-NAT-ero por la sama pordo kondukas tute aliloken: al loka reta adreso kaj al edirekta decido. Tiuj estas malsamaj finpunktoj kun malsamaj protokoloj kaj malsamaj fiaskmanieroj. La kutima signo estas, ke unu adresfamilio funkcias kaj la alia ne, ĉar la restinta ero estis skribita por unu familio kaj neniam reviziita.

Notu la pretendon antaŭ redaktado: familio, ekstera adreso, transporto, pordo kaj la tradukita celo.

La tradukado okazas antaŭ la loka kontrolo

Cel-NAT ŝanĝas la celon de la paketo en la antaŭ-enkursiga stadio, antaŭ ol la kerno elektas inter loka liverado kaj edirekto. Post kiam la celo estas loka reta gastiganto, la paketo prenas la edirektan vojon. Envenaj reguloj por la propra soketo de la enkursigilo neniam estas konsultataj, tial la VPN-registro restas malplena dum la kliento atendas.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Tiu ordo estas la tuta mekanismo, kaj aparataj interfacoj kaŝas ĝin malantaŭ markobutonoj sen ŝanĝi ĝin. La posedanto de la celo ankoraŭ decidas, kiun vojon paketo prenos.

Se la loka reta gastiganto estas la intencita finpunkto, la edirekto estas ĝusta kaj la enkursigilo ne devus ankaŭ aŭskulti tiun pordon.

Konservu unu mapadon kaj forigu la alian

Listigu la NAT-erojn por tiu pordo kaj familio kaj elektu la pluvivanton:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

TCP-ero kun la sama numero estas sensignifa por UDP-fiasko, kaj trakti ilin kiel unu objekton kondukas al forigo de la malĝusta regulo. Kiam la loka soketo devus venki, la posedanto de la konflikta mapado forigas aŭ reverkas tiun unu eron, kaj la envena permeso por la propra pordo de la enkursigilo restas surloke. Nerilataj edirektoj, la administra vojo kaj kopio de la regulkompleto ĉiuj devus postvivi la ŝanĝon.

Se la VPN loĝas sur aparta gastiganto, la edirekto estas la ĝusta objekto. Servo en ujo aŭ virtuala maŝino eble bezonas publikigitan pordon eĉ kiam la skatolo nomiĝas enkursigilo, do sekvu la soketon kaj ĝian nomspacon, ne la etikedon sur la skatolo.

Konfirmu la posedanton de ekstere

Testu ĉiun familion aparte, ĉar IPv6-konekto, kiu finiĝas sur la enkursigilo, diras nenion pri IPv4-konekto, kiun malnova regulo redirektas. Legu la registron de la ricevanta servo por vidi, kiu finpunkto respondis, kaj traktu la sukcesan mesaĝon de la kliento kiel malfortan pruvon. Por senchava testo necesas nova fluo. Sendu sondilon de ekstera gastiganto per nc -zvu 203.0.113.7 1194 kaj legu la registron de la venkinto per journalctl -u openvpn@server -n 20. La aŭskultanto de la enkursigilo mem registras la konekton, dum loka reta gastiganto registras ĝin en sia propra servo.

Konekta spurado tenas ekzistantajn fluojn sur ilia origina mapado, do establita sesio povas postvivi la regulon, kiun vi ĵus riparis.

Post kiam la intencita finpunkto respondas per siaj normalaj identeckontroloj, testu privatan rimedon malantaŭ la tunelo. Atingi la eksteran aŭskultanton estas nur la unua salto; interna enkursigado kaj aplikaĵa rajtigo estas apartaj rezultoj.