Moatte jo SNAT tapasse op in port-oerdracht nei in VPN-subnet?

It trochstjoeren fan in port nei in host dy't efter de eigen VPN-klant fan 'e router sit, mislearret op in manier dy't op in firewallprobleem liket, want it fersyk komt dúdlik oan. De tsjinst registrearret in ferbining, de klant wachtet, en der komt neat werom. De oersetting fan 'e bestimming die har wurk; it werompakket is it part dat wei is. Ien selektive boarne-NAT-regel op 'e router makket dat klear, en it nijsgjirrige part is te besluten hoe smel dy regel wêze kin.

Wêrom't it antwurd in oare wei nimt

In port-oerdracht skriuwt oer wêr't in pakket hinne giet, nea wêr't it wei kaam. It adres fan 'e internetklant bliuwt yn it boarnefjild de hiele wei troch de tunnel, dat de tsjinst oan 'e oare kant sjocht in frjemdling en antwurdet op 'e iennige manier dy't er ken: fia syn eigen standertgateway. Dy gateway is it VPN-konsintraat oan 'e oare kant, dat gjin rûte werom hat nei in willekeurich iepenbier adres.

Sjoch nei in opname op 'e tunnelinterface en de asymmetry is dúdlik: fersykpakketten nei bûten, neat nei binnen. De trochstjoerkeatling liet de stream ta en de tunnel droech it, dus it fallen bart neidat de host oan 'e oare kant al in weromwei keazen hat.

In boarneregel smel genôch om te fertrouwen

Meitsje de router de boarne dêr't de host oan 'e oare kant op antwurdet. Yn dizze yndieling is it WAN-adres 203.0.113.24, it LAN is 192.168.88.0/24, it tunneladres fan 'e router is 172.20.5.1, en de tsjinst antwurdet op 172.20.5.40:8443. De regel hjirûnder past by it pakket nei de oersetting fan 'e bestimming, dêrom neamt er it oersette adres ynstee fan it iepenbiere. Neat dêryn hinget ôf fan it adres fan 'e klant, en dat is krekt it punt.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Elke oerienkomst yn dy rigel bestiet om it oerskriuwen lokaal te hâlden foar ien tsjinst op ien tunnel. Helje de interface of de port fuort en jo skriuwe mear ferkear oer as't it probleem freget, en sa wurdt in rjochte oplossing in riedsel foar de folgjende persoan.

Wannear't in algemiene maskerade de earlike kar is

As de router in protte tsjinsten nei itselde VPN-subnet trochstjoert, wurdt in regel per tsjinst in list dy't gjinien ûnderhâldt. Alles maskearje dat de tunnelinterface ferlit is ienfâldiger en foarsisber, tsjin 'e priis dat de oarspronklike klant foar elke host oan 'e oare kant ferstoppe wurdt. Kies dat as de logboeken dêre net brûkt wurde foar taskriuwing; hâld de smelle regel as se wol brûkt wurde.

De twa opsjes mislearje ek oars. In ûntbrekkende smelle regel brekt ien tsjinst; in brede maskerade dy't te folle past kin stil ferkear oerskriuwe dat al wurke, ynklusyf de eigen útgongferbiningen fan 'e router.

Kontrolearje de tellers foar't jo publisearje

Regels dy't nea passe lykje itselde as regels dy't wurkje oant jo pakketten telle. Lês de tabel werom mei bytetellers foar't in klant ferbynt, ferbyn dan fan in netwurk dat net it LAN is en lês it wer. Twa lêzingen binne wat in gissing yn in feit feroaret. Publisearje de oerdracht pas neidat de twadde beweecht.

iptables -t nat -L POSTROUTING -v -n --line-numbers

In nulteller op 'e boarneregel nei in echte ferbining betsjut dat de oerienkomst ferkeard is, meastentiids om't de bestimming of de port net by it pakket nei de oersetting past. As de teller klimt mar de klant docht noch hieltyd in time-out, is de weromwei reparearre en smyt wat oars it antwurd fuort, dus sjoch dêrnei nei it trochstjoerbelied oan 'e oare kant. Tagong fia in hierpin fanôf it LAN is in apart probleem en hat syn eigen regel nedich, net in bredere ferzje fan dizze.