In LAN-tsjinst publisearje op it eigen adres fan de VPN-gateway

In LAN-apparaat presintearje op ien fan 'e eigen tunneladressen fan 'e gateway kostet ien rigel NAT. De ferbining mislearret noch altyd, want it apparaat dat antwurdet hat gjin idee dat it adres fan 'e kliïnt fia dy gateway berikber is. Folchje it pakket fan 'e kliïnt nei binnen, folchje dan it antwurd werom nei bûten, en de ûntbrekkende helte wurdt fanselssprekkend.

Begjin by it eachpunt fan 'e kliïnt

De kliïnt yn dit foarbyld sit yn 'e VPN-pool 10.62.0.0/24 en ferbynt nei 10.62.0.1 op poarte 8080. Dat adres heart by de gateway sels, dus it pakket komt by de kernel fan 'e gateway oan en net by in oare peer. Efter de gateway is it LAN 172.21.4.0/24. De gateway hâldt 172.21.4.10 en it apparaat dat echt HTTP tsjinnet is 172.21.4.40.

In adres dat by in oare VPN-peer heart is net útwikselber mei it tsjinstadres fan 'e gateway. As de kliïnt ferbynt mei it adres fan in peer, is dêr hielendal gjin gateway-regel by belutsen, en dizze hiele rûnlieding is de ferkearde.

Behein de oersetting fan de bestimming bewust

De smelle ferzje presintearret ien poarte en skriuwt allinnich de bestimming oer. It pakket hâldt syn protokol en syn boarne, en dat makket de rest fan 'e rûnlieding nijsgjirrich.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

In regel sûnder kritearia foar protokol en poarte is de brede ferzje: hy behâldt hokker poarte de kliïnt ek keas en feroaret allinnich it adres. Dat is rjochtmjittich as de hiele host presintearre wurde moat, en ferkeard as ien tsjinst de bedoeling wie. Lês de regel werom en befêstigje de namme fan 'e interface. In DNAT-regel op 'e ferkearde interface past nergens op, wat deselde timeout jout as in ûntbrekkende regel en in oere fersmyt mei sjen nei it apparaat.

Lit de grins fan it trochstjoeren it iens wêze

Oersetting feroaret de kop, it jout gjin tastimming. By in standertferwerppolityk hat de trochstjoerde stream syn eigen akseptaasje nedich, en de weromrjochting hat de regel foar fêststelde ferbining nedich dy't dyn polityk wierskynlik al hat.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

In sûnder betingsten akseptaasje foar elke DNAT-stream is breder as dit ûntwerp en sil ek mappings tastean dy't letter troch immen oars tafoege wurde. Nammje de bestimming en de poarte, en lit de rest ticht bliuwe. As de tellers op 'e trochstjoerregel op nul bliuwe wylst de NAT-tellers omheech geane, wurdt it pakket foar dyn regel weismiten. Lês de folchoarder fan 'e keatlings ynstee fan in twadde kopy ta te foegjen.

It apparaat moat earne antwurdzje

Nei de oersetting sjocht it apparaat in boarne yn 10.62.0.0/24. Syn antwurd giet nei syn standertgateway, dat is de LAN-rûter, net de VPN-gateway, útsein as iets him oars fertelt. Twa regelingen meitsje dat goed en se binne net gelykweardich. In rûte op it apparaat of op 'e LAN-rûter stjoert 10.62.0.0/24 nei 172.21.4.10 en behâldt de boarne fan 'e kliïnt. In beheinde boarneoersetting ferstoppet de kliïnt ynstee efter it LAN-adres fan 'e gateway.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Kies nei wat de tsjinst nedich hat. Polityk per kliïnt en betsjuttingsfolle logs wolle de rûtefoarm; in apparaat dat gjin rûte krije kin, of in tsjinst dy't gewoan in LAN-adres sjen moat, wiist nei de oersette foarm. Gryp net nei in globale masquerade-regel om ien antwurd wurkje te litten. It ferstoppet elke kliïnt foar elke bestimming en brekt stil de polityk dy't fan boarneaadressen ôfhinklik is.

Test net fan 'e gateway sels

In fersyk dat op 'e gateway nei 10.62.0.1 makke wurdt, giet fia de OUTPUT-keatling nei bûten, net fia de ynkommende PREROUTING. It mislearjen of slagjen derfan seit neat oer de regel nei de kliïnt, en sa komme minsken ta de konklúzje dat in wurkjende regel stikken is.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Run in echt kliïntfersyk en lês beide. De conntrack-yngong lit de tapaste oersetting sjen, en de opnames litte sjen oft it fersyk nei it LAN oergie en oft in antwurd werom kaam nei de tunnel. Brûk in nije ferbining nei it feroarjen fan regels, want besteande steat hâldt syn eardere mapping en sil op 'e âlde manier mislearje. Befêstigje dan it hiele petear: it adres fan it apparaat, de tastimming foar trochstjoeren en de rûte fan it antwurd beskriuwe allegear deselde stream.