Pam na all eich LAN gyrraedd gwasanaeth ar gleient VPN

Mae eich twnnel i fyny, mae’r gwasanaeth yn gwrando, ac mae LAN y swyddfa yn dal i gael dim yn ôl. Doedd neb wedi torri’r VPN. O safbwynt y LAN, nid yw cyfeiriad twnnel y gliniadur yn bodoli nes bod rhywbeth yn dweud wrth y LAN sut i gyrraedd yno, a rhaid i’r ateb ddod yn ôl yr un ffordd ag yr aeth y cais allan. Rwyf wedi gweld pobl yn ailadeiladu twnnel hollol iawn deirgwaith cyn i unrhyw un edrych ar y llwybr dychwelyd.

Nid y twnnel sydd wedi torri

Mae’r ddau ben yn eistedd ar ystodau preifat, sef yr achos arferol ac nid camgyfluniad. Mae cyfeiriad fel 10.8.0.6 yn real y tu mewn i’r twnnel ac yn ddim yn unrhyw le arall, felly nid oes rheswm i’r LAN anfon unrhyw beth yno. Cyn cyffwrdd â’r llwybro, cadarnhewch fod y gwasanaeth yn gyrraeddadwy o fewn y twnnel o gwbl: ar y cleient mae ss -ltn yn dangos a yw’r gwrandawr yn rhwymo i 127.0.0.1, i ryngwyneb y LAN, neu i gyfeiriad y twnnel. Nid yw daemon sydd wedi’i rwymo i loopback yn unig yn ateb neb ond ef ei hun, ac nid yw unrhyw lwybr, DNAT na blaenddodiad porth yn newid hynny.

Mae dirprwy ar borth 80 neu 443 yn offeryn gwahanol â gwelededd gwahanol. Mae’n symud ceisiadau, nid pecynnau, felly dyma’r haen anghywir ar gyfer cysylltiad cronfa ddata crai, a chyrraedd amdano yw sut mae’r broblem hon yn gorffen tri offeryn yn ddwfn cyn i unrhyw un fesur unrhyw beth.

Siâp llwybr: dywedwch wrth y LAN ble mae’r pwll

Llwybr statig ar giât y LAN yw’r ateb glanaf pan nad yw’r LAN a phwll y twnnel yn gorgyffwrdd. Cyfeiriwch y pwll at y peiriant sy’n terfynu’r twnnel:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Mae hynny’n trwsio un cyfeiriad yn unig, a dyna pam mae fersiynau hanner-gorffenedig o’r newid hwn yn edrych fel cynnydd. Mae ar ochr y twnnel angen yr hanner cyfatebol, neu mae’r ateb yn gadael y cleient ar ei lwybr rhagosodedig ei hun ac yn marw ar y ffordd:

push "route 192.168.1.0 255.255.255.0"

Ar gyfer is-rwydwaith sydd y tu ôl i un cleient yn hytrach nag y tu ôl i’r gweinydd, mae ar y gweinydd angen llwybr system a chofnod iroute yn ffeil y cleient hwnnw o dan client-config-dir. Heb iroute mae OpenVPN yn gwybod bod y rhagddodiad yn bodoli ac nid oes ganddo syniad pa gleient sy’n berchen arno: mae pecynnau’n cyrraedd ac nid oes gan y daemon ddim i’w paru â nhw.

Dyma’r myth sy’n werth ei enwi. Mae llwybr yn gwneud cyfeiriad yn gyrraeddadwy; nid yw’n gwneud yr ochr bell yn barod i ateb. Mae partneriaid safle-i-safle yn ychwanegu haen arall ar ben hynny, oherwydd dim ond ffynonellau y tu mewn i’r rhagddodiadau yn ei bolisi y mae’r giât bell yn eu derbyn, ac nid yw gliniadur sy’n cyrraedd o bwll cartref y tu mewn iddynt.

Siâp NAT: DNAT i mewn, a’r llinell SNAT mae pawb yn ei hepgor

Pan na allwch gyffwrdd â chiât y LAN, neu eisiau cyhoeddi un porth yn union, mae cyfieithu ar westeiwr y VPN yn gweithio heb unrhyw lwybr ar y LAN o gwbl. Cyhoeddwch y porth, ei anfon ymlaen, a chyfieithu’r ffynhonnell ar y ffordd i mewn i’r twnnel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Y drydedd linell yw’r un sy’n mynd ar goll. Ei hepgor a bydd y cleient yn gweld cyfeiriad gwreiddiol y LAN fel y ffynhonnell, yn ateb drwy ei lwybr rhagosodedig ei hun, ac mae’r ateb hwnnw’n mynd i’r twnnel yn hytrach nag yn ôl tuag at y LAN. P’un a yw’r cysylltiad yn goroesi wedyn sy’n dibynnu ar lwybro na wnaethoch chi erioed ei gynllunio. Gyda SNAT mae’r cleient yn gweld cyfeiriad twnnel y gweinydd, felly mae’r ateb yn dilyn y twnnel yn ôl at yr unig westeiwr sy’n gallu dadwneud y cyfieithiad.

Mae cadarnwedd defnyddwyr yn defnyddio ei henwau cadwyn ei hun ac nid yw’n cynhyrchu’r cyfieithiad hwnnw ar eich cyfer. Ar Tomato mae rheol fewnol yn glanio yn WANPREROUTING ac yna mewn cadwyn hidlo fel wanin, ac mae set rheolau sy’n edrych yn gyflawn yn dal i fod angen llinell POSTROUTING â llaw. Nid yw hynny’n fater o wall cadarnwedd; set rheolau wedi’i hysgrifennu ar gyfer traffig sy’n dod i mewn yn unig ydyw.

Pam mae rheol sy’n edrych yn gywir yn dal i ollwng y pecyn

Nid yw’r rhan fwyaf o’r methiannau hyn yn y rheol rydych chi’n syllu arni. Gwiriwch bedair peth yn y drefn hon, a stopiwch ar yr un gyntaf nad yw’n dal:

• Trefn y cadwyni. Mae iptables -I yn mewnosod ar y brig ac mae -A yn atodi ar y diwedd, felly rheol ganiataol neu flocio gynharach sy’n penderfynu gyntaf.
• Cadwyn anghywir. Mae traffig sydd wedi’i gyfeirio at y llwybrydd ei hun yn croesi INPUT, ac nid yw traffig a anfonir ymlaen byth yn cyffwrdd ag ef. Gall cyhoeddi un gwasanaeth fod angen rheolau yn y ddau.
• Baneri cyfeiriad. Mae -i tun0 yn paru traffig sy’n dod o’r cleientiaid ac mae -o tun0 yn paru traffig sy’n mynd tuag atynt. Mae REJECT â’r baner anghywir yn blocio rhywbeth na fwriadwyd gennych.
• Cyfyngiad ffynhonnell. Mae anfon ymlaen sy’n derbyn un cyfeiriad cleient yn gweithio o’r cleient hwnnw ac yn gollwng pob ffynhonnell arall heb air.

Nid yw rheol â chyfrifydd pecynnau sero ar y llwybr o gwbl, a darllen y cyfrifwyr yw’r ffordd gyflymaf o wahanu problem cadwyn anghywir oddi wrth broblem rheol anghywir.

Y blaenddodiad lleol, pan na all dim ar y LAN newid

Mae blaenddodiad SSH lleol yn osgoi’r cwestiwn cyfan. Nid oes angen llwybr ar y LAN, na chydweithrediad gan firewall y cleient, na phorth wedi’i gyhoeddi yn unman:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Yna mae’r gwasanaeth yn ymddangos ar localhost:3000 y peiriant sy’n rhedeg y twnnel, ac yn unman arall. Dyna’r ffin: un gweithfan, un porth, ac mae’r blaenddodiad yn marw gyda’r sesiwn oni bai bod rhywbeth yn ei ailddechrau. I weinyddwr sy’n gwirio cronfa ddata brofedigaeth mae’n offeryn cywir. I gamera neu sganiwr y mae’n rhaid i bobl eraill gyrraedd, nid yw, oherwydd byddai angen ei flaenddodiad ei hun ar bob defnyddiwr.

Gwiriwch y ddau gyfeiriad cyn ychwanegu rheol arall

Mae cyfieithu’n gadael olion, ac mae eu darllen yn well na dyfalu. Ar westeiwr y VPN mae conntrack -L yn dangos a ddigwyddodd y cyfieithiad o gwbl, mae iptables -t nat -L -n -v yn dangos a symudodd y cyfrifwyr, ac mae tcpdump -ni any port 3000 yn dangos pa gyfeiriad ffynhonnell a gyrhaeddodd mewn gwirionedd. Ar y cleient mae ss -ltn yn cadarnhau bod y gwrandawr ar gyfeiriad y gall y twnnel ei gyrraedd.

Yna dewiswch y siâp rydych chi’n ei gadw. Mae un porth cyhoeddus, llwybr ar gyfer y pwll cyfan, a blaenddodiad ar gyfer un gweinyddwr yn dri ymrwymiad gwahanol, a’u cymysgu yw sut mae setup sy’n gweithio yn dod yn un na all neb ei esbonio chwe mis yn ddiweddarach. Ysgrifennwch pa gyfeiriad sy’n gyrraeddadwy o ble, ac mae’r person nesaf i ddadfygio hyn yn dechrau ar yr ateb yn hytrach na’r twnnel.