In tsjinst op in VPN-klant berikke: omkearde tunnel of DNAT

Sels in laptop efter de NAT fan 'e oanbieder kin in kollega tsjinje, salang't de VPN-server as moetingsplak fungearret. Twa meganismen liede dêrhinne: de klant skillet nei bûten en freget de server om in lústere port te hâlden, of de server publisearret in port en oerset it yn 'e tunnel. Beide lossen itselde berikberensprobleem op en gedrage har oars by falen, tafersjoch en logging. Trije betingsten beslisse hokker yn jo opset heart.

Twa foarmen, ien moetingsplak

Yn 'e earste foarm iepenet de klant in SSH-sesje nei bûten en freget de server om op in keazen port te lústerjen, wylst elke ferbining werom stjoerd wurdt troch dy sesje. Op 'e server wurdt neat trochstjoerd en der bart gjin pakketoersetting, dus de iennige easken binne in SSH-account, in tastiene trochstjoering en in firewallregel foar de port. De tsjinst bliuwt bûn oan loopback op 'e klant, wat meastentiids is wat jo wolle.

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

Yn 'e twadde foarm is de server eigner fan 'e iepenbiere port en skriuwt elke ferbining oer nei it tunneladres fan 'e klant. Dat freget aktivearre IP-trochstjoering, in bestimmingsoersetting by it ynkommen en in boarnoersetting by it útgeand, en it bliuwt wurkjen as der gjin SSH-sesje is. De port heart by de server en net by in sesje, en dat is de eigenskip dy't de measte echte gefallen beslacht.

Gjin fan beide foarmen is fan himsels feiliger. Beide einigje mei ien tsjinstport bleat te stellen foar elkenien dy't it iepenbiere adres fan 'e server berikke kin, en beide bliuwe ôfhinklik fan 'e eigen autentikaasje fan 'e tsjinst.

Betingst ien: moat de port langer as de sesje libje

In omkearde trochstjoering libbet krekt sa lang as de SSH-sesje dy't him makke hat. As de ferbining falt, ferdwynt de lústerer en sjocht de kollega in wegere ferbining ynstee fan in stadich paad. Tafersjoch op it kommando mei in systemd-ienheid en in werstartbelied lossit dat op, en ExitOnForwardFailure=yes makket in mislearre bining daliks sichtber ynstee fan in sesje sûnder trochstjoering efter te litten.

In oersette port oerlibbet werstarts as de regels bewarre wurde, mar it hinget derfan ôf dat de klant itselde tunneladres hâldt. In dynamyske pool dy't de laptop nei in werferbining in oar adres jout, wiist de regel stil nei neat. Reservearje earst it tunneladres, skriuw dan de regel, en behannelje de beide as ien feroaring.

As de tsjinst om trije oere nachts antwurdzje moat sûnder dat immen sjocht, is de foarm mei de troch de server publisearre port dy mei de minste bewegende dielen, want it iennige proses dat oerein bliuwe moat is de tunnel sels.

Betingst twa: wa is eigner fan 'e firewall en de logs

De omkearde foarm hâldt alle belied op twa plakken. sshd beslúttet fia AllowTcpForwarding oft remote trochstjoeringen oerhaas tastien binne, en GatewayPorts beslúttet oft de lústerer oan loopback of oan elk adres bynt. Mei de standertwearde no kin in kollega bûten de server de port net berikke ek al is de trochstjoering slagge, en dat liket in stikken tunnel wylst it eins in biningsadres is.

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

De oersette foarm freget aktivearre trochstjoering en twa regels, en de twadde regel is dêr't de measte resepten misse. It beheinen fan 'e boarnoersetting ta de conntrack-status DNAT betsjut dat allinnich de ferbiningen dy't de bestimmingsregel makke hat oerskreaun wurde, ynstee fan elk pakket dat de server de tunnel yn stjoert.

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

Dy oerskriuwing fernielt ek de taskriuwing. Dêrnei sjocht de klant elke opropper as it tunneladres fan 'e server, wat elke snelheidslimyt per adres yn ien amer gearfettet en ferberget wa't wat stjoerd hat. As taskriuwing fan belang is, einigje dan de ferbining op 'e server of hâld de tastimmingbeslissing dêr en jou in identiteit troch yn in koptekst dy't de tsjinst fertrout. De kar tusken dy beide reparaasjes hinget derfan ôf oft de tsjinst oerhaas in proxy-koptekst lêst.

Betingst trije: ien port of in protte, en wa is eigner fan 'e namme

Ien tsjinst op ien port is it gefal dêr't de omkearde trochstjoering op ynspanning wint. Jo hawwe ien kommando, ien account en ien firewallregel nedich, en opromjen is de sesje deadzje. Ferskate tsjinsten op itselde iepenbiere adres triuwe jo nei de troch de server publisearre foarm, want elke omkearde trochstjoering hat syn eigen serverport nedich en de set groeit mei elke tsjinst.

Nammen meitsje it fierder yngewikkeld. In omkearde trochstjoering kin efter in TCP-proxy sitte dy't op SNI rûtelet, wylst in oersette port meastentiids ien port per tsjinst is. As de tsjinst sels TLS ôfslút en de oarspronklike hostnamme nedich hat, behâldt de proxy-oanpak it en behâldt de DNAT-oanpak it allinnich as de tsjinst dy namme op dy port akseptearret.

Skriuw op hokker fan 'e trije betingsten de foarm besliste. Oars sil de folgjende persoan dy't in twadde tsjinst tafoeget deselde fergeliking mei minder kontekst wer iepenje.

Beslút, en test dan fan bûten

Test it paad fan in netwurk dat gjin rûte nei de laptop hat, en sjoch nei de tellers op 'e server wylst it fersyk rint. Testen fan 'e server nei syn eigen iepenbiere adres bewiist hjir neat, want it pakket wurdt lokaal makke en berikt nea de ynkommende oersettingsheak, dus de test kin slagje wylst it echte paad stikken is.

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

Tellers dy't flak bliuwe betsjutte dat it pakket nea by de regel kaam, wat op 'e oanbieder of de firewall fan 'e host wiist. Tellers dy't bewege wylst de tsjinst wegeret, wize op 'e eigen firewall fan 'e klant of it adres dêr't de tsjinst op lústeret. In tunnel dy't it pakket draacht mar neat weromstjoert is in rûte- of werompaadprobleem, en gjin ien fan dizze trije útkomsten moat ûntbuge wurde troch de klantadapter te bewurkjen. Skriuw op hokker teller beweegde foardat jo eat feroarje, want de folgjende test hat dy basisline nedich.

As de foarm wurket, registrearje dan de port, de eigner en de tafersjochmetoade njonken de tunnelkonfiguraasje. In berikberensreparaasje dy't allinnich yn iens shellskiednis bestiet, is ien werstart fuort fan in werhelle ynsidint.