Kā maršrutēt resursdatora trafiku caur Docker VPN konteineri

VPN konteiners ir tīkla nosaukumu telpa, nevis starpniekserveris. Izvēlieties kopīgu netns, īstu SOCKS klausītāju vai maršrutētu vārteju, pēc tam pārbaudiet izejas ceļu.

Jūsu tuneļa konteiners darbojas, docker compose exec vpn curl -s https://ifconfig.me atbild ar pakalpojumu sniedzēja adresi, un tomēr pārlūks jūsu darbvirsmā joprojām iziet caur jūsu ISP. Šī atšķirība ir sagaidāma. Konteiners, kurā darbojas VPN klients, tur tīkla nosaukumu telpu, maršrutus un tuneļa saskarni, un neko, kas runā HTTP vai SOCKS; porta publicēšana tajā nevar radīt klausītāju, kura nekad nav bijis.

Tas, kur darbojas klients, nosaka dizainu. Brāļu konteiners var pāriet tuneļa nosaukumu telpā, darbvirsmas lietojumprogramma nevar, un maršrutētājam vajag maršrutus, nevis starpniekservera lauku. Ja kartējums ir nepareizs, simptoms ir tāds pats: savienojums noraidīts vai trafiks, kas klusi iet pa veco ceļu.

Pielāgojiet izkārtojumu vietai, kur darbojas klients

Pirms Compose rediģēšanas uzdodiet vienu jautājumu: vai klientu var palaist VPN konteinera tīkla nosaukumu telpā? Viss, kas jau darbojas kā Linux konteiners, var. Pārlūks, IDE vai CLI jūsu darbvirsmā nevar, jo tā starpniekservera iestatījums gaida protokola pakalpojumu, nevis nosaukumu telpu.

ClientArrangementWhat must already exist
Another Compose serviceShares the vpn namespace via network_mode: service:vpnA working tunnel and correct start order
Host browser, IDE or CLIProxy listener inside the namespace, published to host loopbackA configured SOCKS or HTTP proxy and its access rules
Router, VM or phoneThe container as a layer-3 gatewayForwarding, NAT and a return route

Šie trīs nesajaucas. HTTP starpniekservera lauks, kas vērsts uz konteinera tilta adresi, neko nesasniedz, ja vien tur neklausās starpniekserveris, un starpniekservera klausītājs nemaršrutē maršrutētāja trafiku. Vispirms izlemiet, pēc tam sekojiet atbilstošajai sadaļai.

Kopīgojiet tuneļa nosaukumu telpu ar brāļu konteineri

Šis ir lētākais variants, jo tajā nav iesaistīts neviens starpniekservera protokols. Lietojumprogramma pievienojas vpn pakalpojuma nosaukumu telpai un manto tā saskarnes, maršrutus un portu telpu:

services:
  vpn:
    image: your-vpn-client
    cap_add:
      - NET_ADMIN
    healthcheck:
      test: ["CMD-SHELL", "ip link show tun0 >/dev/null"]
      interval: 10s
      retries: 5
  app:
    image: your-app
    network_mode: service:vpn
    depends_on:
      vpn:
        condition: service_healthy

Trīs ierobežojumi izriet no tā, ka nosaukumu telpa pieder citam pakalpojumam. Lietojumprogramma nesaņem savu networks atslēgu, jo tai nav nosaukumu telpas, kam pievienoties. Portu publicēšana pieder vpn, jo tur dzīvo nosaukumu telpa. Un vpn atkārtota izveide iznīcina nosaukumu telpu, kurai pievienojās lietojumprogramma, tāpēc docker compose up -d --force-recreate vpn atstāj jums arī app atkārtoti izveidot; vienkārša restartēšana ne vienmēr ir pietiekama. Compose pakalpojumu uzziņa aptver šo izkārtojumu un tā portu publicēšanas ierobežojumu.

Nepieņemiet, ka atrisinātājs nāk līdzi. /etc/resolv.conf ir fails katram konteineram, nevis tīkla nosaukumu telpas daļa, tāpēc lietojumprogramma joprojām var jautāt resursdatora atrisinātājam, kamēr tās paketes iziet caur tuneli. Lasiet to konteinera iekšienē un iestatiet dns: lietojumprogrammā, kad privātie nosaukumi jāatrisina caur tuneli.

docker compose exec app ip route
docker compose exec app cat /etc/resolv.conf
docker compose exec app curl -s https://ifconfig.me

Ja maršrutu sarakstā ir tuneļa saskarne un adrese ir pakalpojumu sniedzēja, lietojumprogramma ir tuneļa iekšienē. Ja saskarnes nav, app startēja pirms tam, kad vpn bija tunelis, tāpēc izveidojiet app no jauna, tiklīdz vpn ziņo par veselību.

Ievietojiet īstu starpniekservera klausītāju nosaukumu telpā resursdatora klientiem

Darbvirsmas pārlūks nevar pievienoties nosaukumu telpai, tāpēc tunelis ir jāatklāj kā pakalpojums. Palaidiet īstu SOCKS vai HTTP starpniekserveri vpn nosaukumu telpā un publicējiet tikai tā portu:

services:
  vpn:
    ports:
      - "127.0.0.1:1080:1080"
  proxy:
    image: your-proxy
    network_mode: service:vpn
    command: ["--socks", "0.0.0.0:1080"]

Resursdatora puses adrese ir svarīgā puse šim kartējumam. 127.0.0.1:1080 kreisajā pusē tur klausītāju ārpus jūsu LAN; kails "1080:1080" publicē atvērtu starpniekserveri katrai ierīcei, kas var sasniegt jūsu mašīnu.

Konteinera pusei ir savas lamatas. Publicētie porti tiek piegādāti konteinera adresei uz tilta, nevis tā loopback, tāpēc starpniekserveris, kas palaists ar --socks 127.0.0.1:1080 nosaukumu telpā, pieņem brāļu savienojumus un noraida visu, kas nāk pa publicēto portu. Piesieniet to pie 0.0.0.0 un izolācijai paļaujieties uz resursdatora puses loopback saistīšanu. Tas pats noteikums attiecas uz klausīšanās adresi starpniekservera konfigurācijas failā.

Pēc tam izlemiet, kur nosaukumi tiek atrisināti. curl gadījumā --socks5 atrisina resursdatora nosaukumu lokāli, bet --socks5-hostname sūta nosaukumu starpniekserverim; pārlūki rāda to pašu slēdzi ar citu apzīmējumu. Lokāla atrisināšana nopludina vaicājumu arī tad, kad lapa ielādējas caur tuneli.

Uzskatiet konteineri par vārteju tikai ar atgriešanās maršrutu

Maršrutētāji, VM un tālruņi neizmantos HTTP starpniekservera lauku, un dažas lietojumprogrammas pilnībā ignorē starpniekservera mainīgos. Viņu trafika maršrutēšana nozīmē 3. slāni: konteiners pārsūta paketes un tulko adreses tuneļa saskarnē.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Divas lietas ir viegli palaist garām. Klientam vajag maršrutu, kas tā noklusējuma vārteju vērš uz šo resursdatoru, un atbildēm jāatrod ceļš atpakaļ, vai nu pa statisku maršrutu augšupējā maršrutētājā, vai pa NAT saskarnē pret klientiem. Bez viena no tiem tunelis iznes pieprasījumu ārā, un atbilde pazūd.

Tam ir arī visplašākā ietekme. Resursdators, kas darbojas kā vārteja visam LAN, sūta katru nepareizi konfigurētu klientu caur jūsu VPN kontu, un tuneļa kritums vai nu aptumšo LAN, vai atgriežas pie ISP atkarībā no kill switch.

Pārbaudiet izejas ceļu, pēc tam ritiniet atpakaļ secībā

Pārbaudiet šajā secībā un apstājieties pie pirmās kļūdas: izejas adrese nosaukumu telpā, izejas adrese no resursdatora caur starpniekserveri, pēc tam nosaukumu atrisināšana privātam resursdatoram.

docker compose exec vpn curl -s https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 https://ifconfig.me
curl -s -x socks5h://127.0.0.1:1080 http://internal.example/health

Pirmajām divām adresēm jāatbilst pakalpojumu sniedzējam, un trešajai jāatrisinās caur starpniekserveri, nevis jācieš neveiksme ar nosaukuma kļūdu. Atbilstoša pirmā rinda un neveiksmīga otrā rinda nozīmē, ka klausītājs vai publicētais ports ir nepareizs, nevis tunelis.

Atritināšana ir pretēja iestatīšanai. Noņemiet starpniekservera vides mainīgos no čaulas profila un no jebkuras systemd vienības, pēc tam nolaidiet ste ku, lai kopīgā nosaukumu telpa pazūd kopā ar tās īpašnieku. Dzēsiet publicēto portu pirms starpniekservera pakalpojuma dzēšanas, citādi resursdatorā paliek loopback klausītājs, ko neviens nelasa.

Pirms turpināt, apstipriniet četras lietas: jums svarīgais klients patiešām sasniedz tuneli, portus publicē tikai nosaukumu telpas īpašnieks, privātie nosaukumi tiek atrisināti tur, kur bijāt iecerējis, un nekas neklausās resursdatora adresē, kas nav loopback. Katrs no tiem produktīvā vidē klusi neizdodas, un katrs ir vienas rindas pārbaude augstāk.

Saistītie raksti