Objavite LAN uslugu na vlastitoj adresi VPN pristupnika
Prođite proslijeđeni port od klijenta do uređaja i natrag: odredite opseg prevođenja odredišta, zatim odlučite hoće li se odgovori usmjeravati ili prevoditi.
Predstavljanje LAN uređaja na jednoj od vlastitih adresa tunela pristupnika traži samo jedan red NAT-a. Veza i dalje ne uspijeva jer uređaj koji odgovara nema pojma da je adresa klijenta dostupna kroz taj pristupnik. Prođite paketom od klijenta prema unutra, zatim prođite odgovorom natrag prema van i nedostajuća polovina postaje očita.
Pođite od klijentova pogleda
Klijent u ovom primjeru nalazi se u VPN bazenu 10.62.0.0/24 i spaja se na 10.62.0.1 na portu 8080. Ta adresa pripada samom pristupniku, pa paket stiže u jezgru pristupnika, a ne na drugog partnera. Iza pristupnika LAN je 172.21.4.0/24. Pristupnik drži 172.21.4.10, a uređaj koji zapravo poslužuje HTTP je 172.21.4.40.
Adresa koja pripada drugom VPN partneru nije zamjenjiva s adresom usluge pristupnika. Ako se klijent spaja na partnerovu adresu, nikakvo pravilo pristupnika nije uključeno i cijeli je ovaj obilazak pogrešan.
Namjerno ograničite prevođenje odredišta
Uža verzija predstavlja jedan port i prepisuje samo odredište. Paket zadržava svoj protokol i svoj izvor, i to ostatak obilaska čini zanimljivim.
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
Pravilo bez kriterija protokola i porta je šira verzija: čuva koji god port je klijent odabrao, mijenjajući samo adresu. To je legitimno kad se predstavlja cijeli host, a pogrešno kad je jedna usluga bila namjera. Pročitajte pravilo ponovno i potvrdite naziv sučelja. DNAT pravilo na pogrešnom sučelju ne odgovara ničemu, što daje isti vremenski prekid kao pravilo koje nedostaje i troši sat gledanja u uređaj.
Neka se granica prosljeđivanja složi
Prevođenje mijenja zaglavlje, ali ne daje dopuštenje. Uz zadanu politiku odbacivanja proslijeđeni tok treba vlastito dopuštenje, a povratni smjer treba pravilo za uspostavljenu vezu koje vaša politika vjerojatno već ima.
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
Bezuvjetno dopuštenje za svaki DNAT tok šire je od ovog dizajna i dopustit će i mapiranja koja kasnije doda netko drugi. Imenujte odredište i port, a ostalo pustite da ostane zatvoreno. Ako brojači na pravilu prosljeđivanja ostanu na nuli dok brojači NAT-a rastu, paket se odbacuje prije vašeg pravila. Čitajte redoslijed lanaca umjesto da dodajete drugu kopiju.
Uređaj nekako mora odgovoriti
Nakon prevođenja uređaj vidi izvor u 10.62.0.0/24. Njegov odgovor ide na njegov zadani pristupnik, a to je LAN usmjerivač, ne VPN pristupnik, osim ako mu nešto ne kaže drukčije. Dva rasporeda to rješavaju i nisu jednaka. Ruta na uređaju ili na LAN usmjerivaču šalje 10.62.0.0/24 na 172.21.4.10 i čuva izvor klijenta. Ograničeno prevođenje izvora umjesto toga skriva klijenta iza LAN adrese pristupnika.
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
Birajte prema tome što usluga treba. Politika po klijentu i smisleni zapisi žele usmjereni oblik; uređaj kojem se ne može dati ruta, ili usluga koja jednostavno mora vidjeti LAN adresu, pokazuje na prevedeni oblik. Ne posežite za globalnim masquerade pravilom da bi jedan odgovor proradio. Ono skriva svakog klijenta od svakog odredišta i tiho lomi politike koje ovise o izvornim adresama.
Ne testirajte s pristupnika samoga
Zahtjev stvoren na pristupniku prema 10.62.0.1 izlazi kroz lanac OUTPUT, a ne kroz dolazni PREROUTING. Njegov neuspjeh ili uspjeh ne govori ništa o pravilu okrenutom klijentu, i tako ljudi zaključe da je radno pravilo slomljeno.
conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'
Pokrenite stvarni klijentski zahtjev i pročitajte oboje. conntrack zapis pokazuje koje je prevođenje primijenjeno, a snimke pokazuju je li zahtjev prešao u LAN i je li se odgovor vratio prema tunelu. Upotrijebite novu vezu nakon promjene pravila jer postojeće stanje zadržava ranije mapiranje i nastavit će padati na stari način. Zatim potvrdite cijeli razgovor: adresa uređaja, dopuštenje prosljeđivanja i ruta odgovora svi opisuju isti tok.