NAT-ak erabakitzen du zein iturburu-helbide ikusten duen zure VPN zerbitzariak

VPN zerbitzaria zure ordenagailu eramangarriko helbidea paketetik irakurtzen eta erregistro batean idazten ari dela imajinatzen duzu. Irakurtzen duena azken NAT jauziak kanpoko goiburuan jarri zuena da, eta konexioa partekatzen duen telefono batean sarritan ehunka harpidedunek partekatutako helbidea izaten da. Zure makinaren beraren 192.168.x.x helbidea ez da inoiz goiburu horretan internet zeharkatzen, eta tuneleko helbidea zerbitzariak ematen du konexioa dagoeneko altxatuta dagoenean. Beraz, zerbitzariaren erregistroa eta ordenagailuko ip addr bat ez datozenean, ez da bat ere okerra; saio baten geruza desberdinak deskribatzen dituzte.

Hiru helbide, eta bakarra dago erregistroan

Nahasmena hiru helbide batean fusionatzetik dator. Bakoitzak jabe desberdina du, goiburu desberdinean bizi da eta bide desberdinetik iristen da zerbitzarira.

Erdiko errenkada soilik da ezezaguna konektatzeko unean. Zerbitzariak bere pareen taulan, egoera-fitxategian edo fluxu-erregistroan idazten du, daemonaren arabera: WireGuard-ek mutur-puntu deitzen du, OpenVPN egoera-fitxategi batek Real Address gisa etiketatzen du, eta strongSwan-ek IKE_SAren urruneko ostalari gisa jakinarazten du. Balio hori iturri desberdinetik pakete bat iristen den bakoitzean freskatzen da, beraz, inork ezer berrabiarazi gabe aldatzen da.

Beheko errenkada da jendeak identitate-aldarrikapen gisa gaizki irakurtzen duena. Zerbitzariaren konfigurazioan leku bat markatzen du, ez pertsona bat, zerbitzariak bere igerilekutik aukeratu zuelako. Bi erabiltzailek tuneleko helbide bera jaso dezakete egun desberdinetan, eta batek bi izan ditzake bi gailutatik.

Zergatik aldatzen den erregistratutako tuplea tunelea altxatuta dagoen bitartean

Helbideen itzulpena tenporizadorea duen taula da, ez lotura iraunkorra. Etxeko bideratzaileak bere UDP mapaketa mantentzen du azken paketearen ondoren, operadorearen atebideak bere egutegiaren arabera birziklatzen ditu portuak, eta Wi-Fi-tik LTEra pasatzen den telefonoa erabat desberdina den iturburu batekin itzultzen da. Linuxen conntrack-en balio lehenetsiak erreferentzia ona dira hemen: nf_conntrack_udp_timeout 30 segundo da eta streaming bertsioa 120, beraz tunele isil batek bere mapaketa gal dezake erabiltzaileak nabaritu baino askoz lehenago.

Tuneleak bizirik irauten du protokoloak parekidea autentifikatzen duelako, ez helbidea. WireGuard egoerarik gabea da eskua eman ondoren, beraz autentifikatutako edozein paketek gordetako mutur-puntua eguneratzen du eta birkonexioa hurrengo paketean sendatzen da; horregatik dago persistent-keepalive = 25, mapaketa bero mantentzeko geldirik dagoenean. OpenVPNren --float berdin egiten du, autentifikatutako bezero bati helbide eta portu berrietatik jarraitzea ahalbidetuz. float lehenespenez itzalita dagoen 2.4 eta 2.5 bertsioetan, birkonexioak saioa berrezartzen du eta bezeroa berriro konektatzen da.

IPsec hara iristen da pieza mugikor gehiagorekin. IKEv2-k itzulpena antzematen du NAT detekzio-kargetan iturburu eta helmugako hashak alderatuz, UDP 4500 kapsulamendura pasatzen da eta keepalive-ak tuple berrira arte jarraitzen ditu. Keepalive-ak blokeatzen direnean, SA paperean altxatuta geratzen da, norabide bateko trafikoak isilpean gelditzen den bitartean.

Zer egotz diezaiokeen zerbitzariak, eta zer ez

Hiltzea merezi duen mitoa itzulpenak operadorearengandik ezkutatzen zaituela da. Etiketa aldatzen du, ez behaketa. Operadorearen NAT atzean dagoen atebide batek 100.64.0.0/10 espazioa edo harpidedun askok partekatutako helbide publiko bat ikusten du, eta hala ere fluxua ziurtagiri-subjektu batera, WireGuard-en gako publiko batera, esleitutako tunele-helbide batera, byte-kontagailuetara eta denbora-leiho batera lotu dezake. Horietako batek ere ez du zure LAN helbidea behar.

Mugak beste norabidera ere joaten dira. Erregistro batean partekatutako helbide batek atebide bat adierazten du, ez etxe bat; helbide itzuli beretik portu desberdinetan datozen bi saio gailu desberdinak dira; helbide bera bi egun desberdinetan bi harpidedun erlazionatu gabeak izan daitezke portua birziklatu bazen. Pareen gakoak soilik erregistratzen dituen zerbitzari batek ezin du bat bezero batekin lotu kontuen datu-baserik gabe, eta helbideak soilik erregistratzen dituen zerbitzari batek ezin du ordenagailu eramangarri bat telefono batetik bereizi bideratzaile beraren atzean.

Alderatu bi muturrak asmatu ordez

Zer gertatu den argitzeko, harrapatu konexio bera bi muturretan une berean eta alderatu tuplea, ez helbidea. Bezeroan, edozein itzulpenen aurretik:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Ondoren irakurri itzulpen-sarrera bideratzailean edo CGNAT atebidean, eta zer iristen den azkenean zerbitzarira:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Hiru ereduk azaltzen dituzte desadostasun gehienak. Zerbitzariko iturburu-portua tokiko portutik desberdina da helmuga bat datorren bitartean: portuen itzulpen arrunta. Zerbitzariko iturburu-helbidea ez den ISP bloke batekoa da: gutxienez NAT geruza gehigarri bat. Paketeak gelditu egiten dira geldialdi-aldi baten ondoren eta portu berri batekin berriz hasten dira: mapaketak iraungi du, ez da bideratze-akatsa. Denbora-zigiluak segundo bat edo bi baino gehiago bereizita badaude, bi saiakera desberdin alderatzen ari zara.

Non apurtzen duen desberdintasunak gauzak

Zerbitzari-akatsen itxura duten etenak normalean hemen hasten dira. Zure etxeko helbidera ainguratutako sarbide-araua huts egiten du ISPren alokairua aldatzen denean. Itzulitako helbide batekin bat datorren fail2ban arauak atebide horren atzeko harpidedun guztiak blokeatzen ditu aldi berean. Urruneko helbide finkoa duen gune-guneko pare batek gakoak berritzetik uzten du lotura mugikorra aldatzen denean. Tunelearen protokoloa ondo zegoen; kanpoko tupleari buruzko suposizioa ez.

Nahasmen bera zerbitzariaren aldean ere agertzen da. VPN kutxa bera NAT atzean badago, portu-birbidalketa eta birbidalketa-bide funtzionala behar dituzu; strongSwanen birbidalketa-gidak kasu hori IPsec-erako estaltzen du. Helbide pribatu batean soilik irisgarria den zerbitzari batek ez du inoiz bere bezeroek aurkezten duten tuple itzulia ikusten, eta hori bezeroak itzultzearen arazo desberdina da.

Egin itzazu lau egiaztapen hauek ordenan eta gelditu huts egiten duen lehenengoan:

• Harrapatu bi muturretan aldi berean; egiaztatu iturburu-portua, helmuga-portua eta denbora-zigiluak bat datozela.
• Irakurri zerbitzariaren pare-zerrendan orain duen helbidea, ez espero zenuena.
• Egiaztatu conntrack edo NAT taula sarreraren eta hari geratzen zaion bizitzaren bila.
• Egiaztatu bezeroaren tunele-interfazearen helbidea zerbitzariak esleitutakoarekin bat datorrela, ez LAN helbidearekin.

Bi harrapaketek tuplean bat egiten badute eta tuneleak huts egiten jarraitzen badu, itzulpena ez da zure arazoa; jarraitu eskua ematera eta tunelearen barneko bideratze-taulara.